Applying Additional Workflow Rules and Controls

Sub Banner

The Workflow App can be configured to control the order and sequence in which a Ticket can move through each workflow state (see Capturing & Maintaining Workflows), the conditions under which a workflow applies to a Ticket (see Specify Conditions under which a Workflow Applies) and who is responsible and able to move the Ticket to the next state in the workflow (see Applying User Role Based Control).

 

However, it will usually be the case that some or all of the transition process will need to be implemented.

 

*Note:
This procedure requires a significant amount of manual effort and a detailed knowledge and understanding of the Zendesk customization capabilities.
As such it is usually the case that a qualified CloudSet Implementation Consultant performs these tasks as part of the workflow implementation service.

 

This is achieved using regular Zendesk triggers. The architecture of these triggers covers the following types of triggers:

  • Starting a Workflow - selecting the correct starting position for a workflow
  • Managing Transitions - implementing the switching of Groups between stages (as designed)
  • Ending a Workflow - syncing completion with the custom status & system status

Starting processes can be a single trigger (e.g. Close Account) or alternative triggers (e.g. Change Route Type (Quebec), since the transition may be location based. The conditions typically involve the following elements:

  • Ticket creation event
  • The selected process

The actions typically involve the following elements:

  • Defining the Group to transition to
  • Defining the first transition workflow step

Managing transition are similar in regard to sensing the previous & current workflow step and then setting the next workflow step. It also important that the assignee is removed, such that the group can be re-assigned to comply with the way re-assignment in Zendesk works.
In conjunction with the transitions step implementation it is sometimes required to expose a mandatory field. CloudSET Conditional Fields and CloudSET Mandatory Fields are used to achieve this.
The Ending of a workflow is marked by a synchronization of the Completed stage with the custom solved stage and the system solved stage. This is achieved by a trigger called Solve when Workflow Completes. It contains many conditions linked to the previous step i.e. where it transitioned from. The list contains all the completion paths from processes as some have more than one branch.

Applying Additional Workflow Rules and Controls

Sub Banner

Applying Additional Workflow Rules and Controls

The Workflow App can be configured to control the order and sequence in which a Ticket can move through each workflow state (see Capturing & Maintaining Workflows), the conditions under which a workflow applies to a Ticket (see Specify Conditions under which a Workflow Applies) and who is responsible and able to move the Ticket to the next state in the workflow (see Applying User Role Based Control).

 

However, it will usually be the case that some or all of the transition process will need to be implemented.

 

*Note:
This procedure requires a significant amount of manual effort and a detailed knowledge and understanding of the Zendesk customization capabilities.
As such it is usually the case that a qualified CloudSet Implementation Consultant performs these tasks as part of the workflow implementation service.

 

This is achieved using regular Zendesk triggers. The architecture of these triggers covers the following types of triggers:

  • Starting a Workflow - selecting the correct starting position for a workflow
  • Managing Transitions - implementing the switching of Groups between stages (as designed)
  • Ending a Workflow - syncing completion with the custom status & system status

Starting processes can be a single trigger (e.g. Close Account) or alternative triggers (e.g. Change Route Type (Quebec), since the transition may be location based. The conditions typically involve the following elements:

  • Ticket creation event
  • The selected process

The actions typically involve the following elements:

  • Defining the Group to transition to
  • Defining the first transition workflow step

Managing transition are similar in regard to sensing the previous & current workflow step and then setting the next workflow step. It also important that the assignee is removed, such that the group can be re-assigned to comply with the way re-assignment in Zendesk works.
In conjunction with the transitions step implementation it is sometimes required to expose a mandatory field. CloudSET Conditional Fields and CloudSET Mandatory Fields are used to achieve this.
The Ending of a workflow is marked by a synchronization of the Completed stage with the custom solved stage and the system solved stage. This is achieved by a trigger called Solve when Workflow Completes. It contains many conditions linked to the previous step i.e. where it transitioned from. The list contains all the completion paths from processes as some have more than one branch.

Applying Additional Workflow Rules and Controls

Sub Banner

The Workflow App can be configured to control the order and sequence in which a Ticket can move through each workflow state (see Capturing & Maintaining Workflows), the conditions under which a workflow applies to a Ticket (see Specify Conditions under which a Workflow Applies) and who is responsible and able to move the Ticket to the next state in the workflow (see Applying User Role Based Control).

 

However, it will usually be the case that some or all of the transition process will need to be implemented.

 

*Note:
This procedure requires a significant amount of manual effort and a detailed knowledge and understanding of the Zendesk customization capabilities.
As such it is usually the case that a qualified CloudSet Implementation Consultant performs these tasks as part of the workflow implementation service.

 

This is achieved using regular Zendesk triggers. The architecture of these triggers covers the following types of triggers:

  • Starting a Workflow - selecting the correct starting position for a workflow
  • Managing Transitions - implementing the switching of Groups between stages (as designed)
  • Ending a Workflow - syncing completion with the custom status & system status

Starting processes can be a single trigger (e.g. Close Account) or alternative triggers (e.g. Change Route Type (Quebec), since the transition may be location based. The conditions typically involve the following elements:

  • Ticket creation event
  • The selected process

The actions typically involve the following elements:

  • Defining the Group to transition to
  • Defining the first transition workflow step

Managing transition are similar in regard to sensing the previous & current workflow step and then setting the next workflow step. It also important that the assignee is removed, such that the group can be re-assigned to comply with the way re-assignment in Zendesk works.
In conjunction with the transitions step implementation it is sometimes required to expose a mandatory field. CloudSET Conditional Fields and CloudSET Mandatory Fields are used to achieve this.
The Ending of a workflow is marked by a synchronization of the Completed stage with the custom solved stage and the system solved stage. This is achieved by a trigger called Solve when Workflow Completes. It contains many conditions linked to the previous step i.e. where it transitioned from. The list contains all the completion paths from processes as some have more than one branch.

Applying Additional Workflow Rules and Controls

Sub Banner

Applying Additional Workflow Rules and Controls

The Workflow App can be configured to control the order and sequence in which a Ticket can move through each workflow state (see Capturing & Maintaining Workflows), the conditions under which a workflow applies to a Ticket (see Specify Conditions under which a Workflow Applies) and who is responsible and able to move the Ticket to the next state in the workflow (see Applying User Role Based Control).

 

However, it will usually be the case that some or all of the transition process will need to be implemented.

 

*Note:
This procedure requires a significant amount of manual effort and a detailed knowledge and understanding of the Zendesk customization capabilities.
As such it is usually the case that a qualified CloudSet Implementation Consultant performs these tasks as part of the workflow implementation service.

 

This is achieved using regular Zendesk triggers. The architecture of these triggers covers the following types of triggers:

  • Starting a Workflow - selecting the correct starting position for a workflow
  • Managing Transitions - implementing the switching of Groups between stages (as designed)
  • Ending a Workflow - syncing completion with the custom status & system status

Starting processes can be a single trigger (e.g. Close Account) or alternative triggers (e.g. Change Route Type (Quebec), since the transition may be location based. The conditions typically involve the following elements:

  • Ticket creation event
  • The selected process

The actions typically involve the following elements:

  • Defining the Group to transition to
  • Defining the first transition workflow step

Managing transition are similar in regard to sensing the previous & current workflow step and then setting the next workflow step. It also important that the assignee is removed, such that the group can be re-assigned to comply with the way re-assignment in Zendesk works.
In conjunction with the transitions step implementation it is sometimes required to expose a mandatory field. CloudSET Conditional Fields and CloudSET Mandatory Fields are used to achieve this.
The Ending of a workflow is marked by a synchronization of the Completed stage with the custom solved stage and the system solved stage. This is achieved by a trigger called Solve when Workflow Completes. It contains many conditions linked to the previous step i.e. where it transitioned from. The list contains all the completion paths from processes as some have more than one branch.