Workflows 

Pointers 

1. Workflows can be configured for All Customers as well as for a specific customer, but not site-specific.
   
2. This setting is module-specific. Separate workflows for incident requests and service requests can be configured.
   
3. If an asset workflow is associated with All Customers, the product type selected for that workflow cannot be used in customer-specific asset workflows.
   
4. The product type selected in a customer-specific asset workflow cannot be associated with All Customers. However, it can be associated with other customer-specific asset workflows.
   
5. The field values will be listed based on the chosen customer.
   
6. Auto Port : Triggers transition automatically based on rules, conditions, or events. 
   
7. Manual Port  : Requires user intervention to trigger the transition. Users with appropriate permissions can initiate transitions from the details page of their corresponding modules.
   
8. Guided Path: Use the guided path to restrict status changes and allow only status movement defined in the workflow. A workflow following the guided path will be notified to users via the workflow execution details pop-up on their respective details page.
   
9. To enable the guided path globally, go to the module-specific workflow list view and click Global Workflow Settings.
   

1. To enable the guided path specific to a workflow, go to the workflow editor. Click Actions > Manage Status and enable the required option.
   

1. You can convert a life cycle to a workflow. Go to the required module-specific life cycle list view, click the gear icon beside the relevant workflow, and click Create as Workflow.
   

Requests 

Incident 

Use case: Automated technician assignment and notification workflow for high-priority network incident s

1. Automatically assign and notify a technician.
   
2. If the incident approval requires further clarification due to a lack of information, such as domain specifications, impact details, etc., assign a different technician automatically and notify the requester about it.
   
3. Once the approval is granted, assign a network-level technician automatically for resolution.
   
4. When the network technician manually marks the incident as Resolved, automatically close the request.
   

1. Flow Node – Add the initial request status (Open) to the workflow editor.
   
2. Condition Node (IF) – Check for high-priority network incident when a request is opened.
   
3. Action Node (Field Update)– Assign the initial technician.
   
4. Action Node (Notification) - Notify the assigned technician.
   
5. Flow Node – Mark the request as Assigned.
   
6. Condition Node (Switch) - Direct the workflow based on the approval status:
   
7. If Pending for Clarification – Assign another technician by using a Field Update action node. Mark the request as Pending Verification.
   
8. If Approved – Assign the request and notify the Network Support Group. Mark the request as In Progress.
   
9. If Rejected – Notify the approver and requester to close the request. Mark the request as Closed.
   
10. Use the Manual Port in the In Progress flow node to close the request automatically only when the status is manually marked as Resolved by the network-level technician.
    

1. Create an incident workflow for Zylker.
   

1. Configure the workflow editor as shown. Learn more.
   

1. Save the workflow and associate it with the relevant request templates.
   

Service Requests 

Use case: Service Request Onboarding Workflow 

1. The HR team at Zylker wants to create a workflow for user on-boarding request. Their workflow requirement is listed below:
   
2. When a user on-boarding request is raised, check if the Employee Type field is filled.
   
3. If the Employee Type field is not filled, send periodic reminders until the field is updated. If the field is not updated after a certain period of time, automatically change the status to Waiting for End User and wait for the field to be updated.
   
4. Once the Employee Type field is updated, based on its value, trigger the necessary approval and specific tasks.
   
5. If the approval is rejected, update the status to Rejected and close the request.If the approval is accepted and all tasks are completed, close the request.
   

1. Go to Setup > Customization > Additional Fields.
   
2. Add a new field called "Employee Type" as a pick list field with the values "Permanent" and "Contract".
   
3. Go to Setup > Customization > Change Management > Stage and Status.
   
4. Add custom statuses such as "On-boarding Tasks in Progress" and "New Employee On-boarded". Other statuses will be available by default.
   

1. Go to Setup > Automation > Workflows.
   
2. Select Service Request from the module filter.
   
3. Click New Workflow.
   
4. Add a status node as Open and connect with the start node.
   

1. Add the IF node and set the condition Employee Type is empty.
   

1. The IF node will have two outputs: Yes or No. If the field is empty (Yes), connect the next node Status - Waiting for End user.
   

1. Configure a Timer node as shown below:
   

1. If the Employee Type field is not updated by the end of the timer (which is 1 day), add the Wait For node with the criteria Employee Type is not empty, as shown:
   

1. If the Employee Type field is updated, the timer will abort and move to the next node Switch. Add the switch node with the options Permanent/Contract, as shown:
   

1. Based on the selected value in Employee Type, configure the workflow as follows:
   
1. If the Employee Type field is Contract: Add a task node and connect it as shown below. Set the task to Wait for task completion. Connect this task with the status node New Employee Onboarded and the End node.
   

 

1. If the approval is Approved, add a Field Update node to change the approval status and move the status to Onboarding Task - In progress by adding the status node, as shown:
   

1. From the status node Onboarding Tasks - In Progress, split the workflow to handle multiple tasks for each group and join all operations together.
   
1. To split the workflow for multiple operations, add a Fork Branch node called Split as shown below.
   

1. From Split, add three task nodes for IT, Legal, and Facilities. Configure the respective groups and select "Wait for task completion".
   

1. In addition to task nodes, use the Resource node with switch criteria as shown below and connect it with the Split node as shown in the above screenshot. If the resource is selected as Yes, add another task node to verify the agency-related documents.
   

1. Connect all these tasks together by using the Join node. Ensure the join node is configured to execute only when All forked paths are completed.
   

1. Add the Notification node to send a final notification to the hiring team and connect it with the Join node.
   

1. After the final notification, add the Status node and connect it to New Employee Onboarded.
   

1. Handle the rejection process by adding the Field Update node, connecting it with the rejected status, and then connecting it with the Status node Rejected, as shown:
   

1. Connect the node with the status node New Employee Onboarded and the End node.
   

Changes 

Use case: Failed Task – Redirect Path

1. Reroute the process
   
2. Alert stakeholders
   
3. Update the implementation status to On Hold and provide a clear description for the status change.
   

1. Flow Node: Stage - Implementation
   
2. Action Node: Task
   
1. Select the relevant deployment task or create a new task by clicking + New Task.
   
2. Enable Wait for Task Completion to pause workflow progression until the task is completed.
   
3. Enable Setup Alternate Path on Error to configure what happens if the task fails to execute.
   
4. On the canvas, define the alternate route from On Error on the task node.
   
3. From On Error, add a Fork branch node.
   
4. Action Nodes:
   
1. Custom Function: Draft a Deluge script to log the failure as a request automatically with technical details such as an error code or timestamp. 
   
2. Notification: Draft an email notification template to notify the Change Owner or Implementation Team about the logged request and implementation update.
   
3. Field Update: Update the following change fields to give stakeholders a clear idea that the change is paused due to a workflow-level failure and awaits manual intervention.
   
4. Implementation Status → On Hold
   
5. Description → Deployment task execution failure due to <insert_reasons>.
   
5. Add a Join branch node and link it to the required flow node to continue the process after completing all actions.
   

1. Define the deployment task under Setup > Custom Actions > Tasks. You can also add new tasks by clicking + New Task on the Task action node pop-up while configuring the workflow.
   
2. Create a picklist additional field Implementation Status and add it to the change implementation template.
   

1. Go to Setup > Customization > Additional Fields > Change and create a picklist additional field as follows:
   

1. Under Setup > Template & Forms > Change Template, go to the required change template and add the field to the Implementation stage as shown:
   

1. Go to Workflows.
   
2. Select Changes from the module filter and click New Workflow.
   
3. Since the change has to be deployed immediately, choose the Type as Emergency.
   
4. Choose Zylker customer.
   

Change Approval Process    

Use Case: Pre-Approved Change 

1. To efficiently manage scheduled and recurring maintenance changes, go to the Maintenance module.
   
2. Click the module filter drop-down menu and select Change.
   

1. Go to Setup > Customization > Change Management > Change Type.
   
2. Click  beside each change type to set it as pre-approved.

Use case: CAB Approval (Without Pre-Approval) 

1. Navigate to the specific workflow in question.
   
2. Add an approval node next to the CAB Evaluation stage.
   
3. Connect Approval Pending of the CAB Evaluation stage to the approval node.
   
4. Link Approved (output) of the approval node to the Approved (input) of the CAB Evaluation stage to reflect the change as approved.
   
5. Repeat the process for the Rejected status.
   

Workflow Transition  

Use case 1: Managing High Priority Requests     

1. Manual Review: The manager reviews the request and manually approves or rejects it.
   
2. Automatic Approval (as Fallback): If no action is taken by the manager within two days, the request will be approved automatically to prevent unnecessary delays.

1. The Manual port handles the manager’s actions.
   
2. Set a Timer at the Auto port to trigger the system action after two days.
   

Use case 2: Automatically cancel request if user does not respond on time 

1. Send periodic reminders to prompt a response.
   
2. If the user does not reply within a set time, cancel the request automatically.
   

1. The Manual port handles the user’s response.
   
2. Set a Timer at the Auto port to cancel the request after two days if no response is received.