Introduction

Workflows and automation in Zluri help administrators automate the onboarding and offboarding of employees.

To start with onboarding and offboarding workflows let's start with understanding how workflows are segregated.

Onboarding Workflows

Workflows are divided into drafts, playbook runs & automation rules.

OnBoarding vs OffBoarding

What is OnBoarding

Provisioning of users to SaaS applications including Giving Applications, license provisioning, adding to groups etc.

What is OffBoarding

Deprovisioning of users to SaaS applications including Removing Applications, License Deprovisioning, Removing from groups etc.

Best Practices:

1. Add integration with all the Applications that are used in the organization.

→This will help create Workflow to its best with all actions available.

Steps To Setup a Draft:

What is a Draft?

• Drafts are workflows that a user/admin initiates for performing actions. (These drafts get auto-saved as they get edited)

• Zluri provides a draft as a feature that maintains a history of previously edited workflows.

• These drafts can be saved as Playbooks and executed to complete a workflow.
  
  

  
  

  
  
  Setting up a Draft

• Head to Workflows section→ Draft→ + New workflow

• Select users you want to set up a draft for, Selecting users is Mandate while creating a Draft Playbook. (If the idea is setup a playbook without a user, then Head to Playbook and create a playbook)

• Selecting the applications: The plus icon on the right center of the screen is from where you add Application (These applications are those for which you want to Provision/Deprovison for based on Use Case)
  
  

• What can some use cases look like for a Draft? → Creating a Draft for users being Onboarded on a Specific Date, a Draft for users being provisioned with a license in a specific Department.
  
  

Adding Actions in a Playbook

• The plus icon on the right center of the screen is from where you add Applications (These applications are those for which you want to Provision/Deprovison based on Use Case)

• Once an Application is selected, Make sure the Integration (if available) is connected, and the instance is selected (The instance is selected from the right top of the Application) 

Setting up actions

”Add an action” for each application will drop open all available actions for the specific application.

(Based on the use case, continue to configure the actions or remove them )

Automated actions vs manual actions

Actions are of two Types 1. Automated actions  2. Manual Actions

Automated Actions: These actions will be taken automatically by Zluri once configured.

Setting up manual Action

• Manual Action: These actions indicate that the Application has no Open API for which Zluri can take Action; in this case, Zluri helps with Manual tasks where the action can be assigned to different stakeholders.

• Manual Actions work as a checklist of actions that need to be performed in cases where no automated Task is available by sending out an email.

• Manual tasks come with built-in templates to select from; these manual tasks can be assigned to Roles and specific users.

• Manual actions email expires 48 Hours after the due date if no action is taken.
  
  

Best Practices

1. Include only the actions needed for the particular use case.

2. Ensure that the Application is integrated and the Instance is chosen; this Will take action only on the Specific application account.

3. Every action in red indicates that it needs to be configured, and each action needs to be configured.

4. Actions with a “Task” icon, Indicate “Manual Action” → Manual tasks where the action can be assigned to different stakeholders.
   
   

Zluri Actions

 Zluri provides several internal actions to set up across applications and independent actions.

1. Zluri Actions Within Application
   
   

• Add user to system: Use this to add a user to the application in Zluri’s system.

• Add a role to a user in the app: Use this Zluri action to add a role for a user in Zluri’s system.

• Update the status of the user in the app: Use this action to update the status to active or inactive for a user in Zluri’s system

• Remove all licenses for a user: Remove all licenses assigned to the user for a specific app in Zluri’s system.
  
  

2. Zluri’s independent action
   
   

• Zluri's independent action offer interactions for “sending mail.”

• Send workflow sending a summary 

• Make HTTP Request custom HTTP request can be added as well
  
  

Send Custom email

-Custom emails are sent to the users that the playbook is Triggered, along with enablement of in-mail “CC”.

• Send workflow sending a summary.

• Zluri provides comprehensive summary emails for both Onboarding and Offboarding Workflows which contain all information regarding all the actions.
  
  
  

Making an HTTP request

• Zluri action Make an HTTP request that can be set up with GET, POST, and PUT  API calls and pass the correct parameters.

• HTTP request is useful in use cases like custom API call for an On-prem application, Calling API for a non-integrated application, communicating with an unknown application using API etc.

Scheduling actions

What is Schedule Action?

 Schedule actions to run individual actions at a specified time after initiating the workflow.

Use Case Example: 

1. You want to add the user to SSO today but onboard them after seven days

Setup: 

Any action that can be scheduled doesn't matter if it's an integration automated action or a manual action.

To Set it up click Edit action and select the Schedule button.

=>

Adding approver to action

What is Approver on Actions?

Seek approval from stakeholders before you run an action.

Setup: 

Any action that can be added for an approver doesn't matter if it's an integration, an automated action or manual action integration.

To Set it up click Edit action and select the Approve button. You can even add a group email as an Approver.

Best Practice:

• Good to assign Approver to App Owner/To someone who has application access to streamline the process. This will ease the approval and provisioning process.
  
  

Use Case:

1. You want to onboard only when an admin approves the action
   
   

Break on error

What is Break on Error

Break on Error is a toggle to end the Action flow when an error occurs.

Toggle on the Break On Error when the action depends on the previous step/Action.

Usecase

1. You want to break execution at any point of failure to avoid incomplete onboarding/offboarding.
   
   

Saving and Running a Draft

• Every PlayBook will Autosave at each step.

• Each draft/playbook can be saved for future use as a playbook.

• Playbook will execute only when all actions are set up to their best with all the required fields filled up.

• Automation Rules act as a Trigger to execute a Playbook.
  
  

Automation and Why a Rule?

What is an Automation rule?

• Automation rules eliminate the need to perform manual executions of Playbooks and repetitive tasks by allowing your teams to automate their processes and workflows. With our simple rule builder, you can configure powerful automation rules to handle even the most complex scenarios.

• Rules allow you to automate actions within your system based on your set criteria. Automation rules are made up of three parts:

• When (Triggers): Every rule starts with a trigger. They kick off the execution of your rules. Triggers will listen for events in Jira, such as when an issue is created, or a field value is changed. 

• Conditions: Conditions allow you to narrow the scope of your rule. They must be met for your rule to continue running, for example, if the user changes, last active, role change etc.
  Then (Actions): Actions that are the doers of your rule. They allow you to run a Predefined playbook based on use cases.
  
  

Setting up a rule

Head to Workflows—>Automation Rule—> +New Rule —>Setup the “When”, “Condition”, and “Then”.

Supported Trigger in Onboarding

1. User is marked for onboarding: When a user is manually marked for onboarding in the Users -> Mark for onboarding section.

2. A new user is discovered: When a user is detected in zluri via any source, be it MANUAL, SSO, DIRECT INTEGRATIONS OR HRMS.

3. User status changes to active: When a user’s status changes to active in zluri via any source, be it MANUAL, SSO, DIRECT INTEGRATIONS OR HRMS.
   
   

Supported Triggers for Offboarding

1. User is marked for offboarding: When a user is manually marked for onboarding in the Users -> Mark for offboarding section.

2. User is marked as suspended: When a user’s status changes to suspended in zluri via any source, be it MANUAL, SSO, DIRECT INTEGRATIONS OR HRMS.

3. User status changes to inactive: When a user’s status changes to inactive in zluri via any source be it MANUAL, SSO, DIRECT INTEGRATIONS OR 
   
   

Supported Conditions:

1.   Reporting Manager

2.   User Designation

3.   Last Active

4.   User Account Type

5.   Critical Apps Used

6.   Primary Source

7.   User Department

8.   Role

9.   Created At

10.   Risk Level

11.   Apps Used

12.   Usage

13.   User Status
    
    

Executing an Automation Rule

• The automation rule follows a Priority order, which indicates the order in which the rules will trigger; this priority can be interchanged with a drag and reorder icon beside the Priority order. (To keep in mind, A rule with a similar trigger condition will execute only once)

• If two active rules have the same condition and trigger, the rule with the highest priority will execute and stop executing the other rule.

• All rules can be Toggled between “Active” and “Inactive” based on requirements.
  
  

Onboarding Rules

• The Automation feature can handle onboarding new employees, reducing any manual dependency on the various teams within an organization and ensuring maximum efficiency.

• Specific triggers can be set up to ensure the right steps are taken when certain trigger situations are met. Zluri currently works with many triggers ranging from the user, account type, user status, source and created at. 

• Once these events occur, the intelligent automation system verifies the conditions set by the users to increase further the customizability providing greater control over the automated onboarding process. 

• The right onboarding playbook can then be triggered ensuring that employees are onboarded seamlessly. Once set, the rule can continue to function without any manual intervention.
  
  

Offboarding Rules

• The Automation feature can handle offboarding of scenarios, reducing manual dependency on the various teams within an organization and ensuring maximum efficiency.

• Specific triggers can be set up to ensure the right steps are taken when certain trigger situations are met. Zluri currently works with many triggers, including user, account type, user status, source and reporting manager. 

• Once these events occur, the intelligent automation system verifies the conditions set by the users to increase further the customizability providing greater control over the automated onboarding process. 

• The right onboarding playbook can then be triggered ensuring that employees are onboarded seamlessly. Once set, the rule can continue to function without any manual intervention.
  
  

—> Trigger in Automation rules

• This is the Trigger for the Rule to initiate the process.

—> Condition in automation

• Conditions allow you to narrow the scope of your rule. They must be met for your rule to continue running.

—> Then

• Selected playbooks execute.
  
  

Best Practices:

1. Have a playbook in place that needs to be Automated.

2. Have the playbook Configured with the right actions

3. The Automation rule will only trigger once the condition matches the post-setting up of the Rule.
   
   

Viewing the audit log of the workflow

Auditing workflow runs:

• Logs on workflow runs can be seen on “Recent Runs.”
  
  
  

• Every Playbook that is executed can be traced under the Recent runs.

• The Audit helps trace between different Statuses of execution

1. Completed

2. Completed with errors

3. Failed

4. Pending 
   

• Clicking on the View log opens a Detailed summary of the Status of each action.
  
  

• Each failed Automation action can be retired or Admins also have the option to Convert to a manual Task to assign the task ownership.
  
  

• Failed Manual tasks have multiple approaches the admin can take
  
  
  

1. Send Reminders: This resends the Email notification to the initial assignee.

2. Reassign: This enables the change of Owner to send the ownership of the manual task.
   
   

3. Mark as completed in the Email notification: Triggers the workflow action to be completed.

4. Cancel Task: Cancels the task.
   
   

Using a playbook across the platform

1. User:

Selecting users from the user screen enables the “Run a Playbook” Trigger, choosing from Onboarding and Offboarding a Playbook.

2. Application users: 

Heading to the Application and selecting users, enable the “Run a Playbook” Trigger, choosing from Onboarding and Offboarding a Playbook. This enables use cases when users from a specific application might want to be provisioned/de-provisioned with licenses or OnBoarded/Offboarded from applications.

3.  Optimization:

Application optimization helps organizations to get the potential savings & wastage at an application level at all organizations combined.

Use cases for Playbook (Best practices)

1. Add a new user to a specific Department:

• Making a playbook with all the applications and licenses necessary for a certain department will make it easier to add users directly.

2. Creating a playbook to Onboard/Offboard users on a specific date:

• Making a playbook for a custom requirement for specific users with activities on specific dates

3. Creating a playbook for App license Provisioning/Deprovisioning

• Making a playbook for App license will ease transfer/Provision deprovision of the license of a specific application