Planning and Preparing for Workflow Configuration

Sub Banner

Before attempting to configure the Workflow App it is recommended that the end to end process is modeled showing each of the transitions involved throughout the life cycle of a Ticket and the role responsible for performing each step.

This model can then be used to identify the various objects and properties to be captured and mapped using the Workflow App.

Design each Workflow using a Process Model

The name of the Process Model (1) corresponds to the name of the Workflow configured in the Workflow App.

Identify Workflow States

The flows between the processes in a swim lane diagram (2) indicate when there is a change in the state of the Ticket within the workflow,

The name of each process (3) provides an indication of the transition that has taken place and from which the name of each state should be derived.

These names will be required during the configuration of the Workflow App to populate the list of states to be used in each workflow (see Configuring States for use within Workflows).

Identify Workflow State Mappings

Having identified the state names, the data flows and decisions (4) can be used to determine the order and sequence of each state, i.e. when in a particular state, which of the workflow other states could follow next.

This information will be required when configuring the sequence and order of the state transitions within each workflow using the Workflow App (see Capturing & Maintaining Workflows).

Identify User Roles

The Roles involved involved in each swim lane (5) should be used to identify when there is a requirement to restrict who is allowed to transition a Ticket from one workflow state to another.

These Roles are required during configuration of the end user roles that can be utilized in the Workflow App when specifying who can complete the transition (see Applying User Role Based Control).

Identify Workflow Preconditions

It is possible that some of the steps and data flows in the process model occur before the workflow to be implemented within Zendesk kicks in.

For example, an initial step might involve the prioritization and or categorization of a Ticket and the use of a workflow depends upon one or more priority values and/or categories (6).

These conditions and rules should be identified in the process model and used during the configuration of the Workflow App to determine when a workflow applies (see Specify Conditions under which a Workflow Applies).

Identify Additional Workflow Rules

Where a data flow passes between swim lanes (7) then this is an indication that there is a need to hand over control of the workflow to an alternative role player.

Also the full description of a process or step might identify the need to expose or hide one or more fields in the Ticket form, or automatically set the value of fields as part of the transition between workflow states.

This information is required when designing and implementing triggers and/or configuring additional widgets to fully implement the transitions (see Applying Additional Workflow Rules and Controls).

Planning and Preparing for Workflow Configuration

Sub Banner

Planning and Preparing for Workflow Configuration

Before attempting to configure the Workflow App it is recommended that the end to end process is modeled showing each of the transitions involved throughout the life cycle of a Ticket and the role responsible for performing each step.

This model can then be used to identify the various objects and properties to be captured and mapped using the Workflow App.

Design each Workflow using a Process Model

The name of the Process Model (1) corresponds to the name of the Workflow configured in the Workflow App.

Identify Workflow States

The flows between the processes in a swim lane diagram (2) indicate when there is a change in the state of the Ticket within the workflow,

The name of each process (3) provides an indication of the transition that has taken place and from which the name of each state should be derived.

These names will be required during the configuration of the Workflow App to populate the list of states to be used in each workflow (see Configuring States for use within Workflows).

Identify Workflow State Mappings

Having identified the state names, the data flows and decisions (4) can be used to determine the order and sequence of each state, i.e. when in a particular state, which of the workflow other states could follow next.

This information will be required when configuring the sequence and order of the state transitions within each workflow using the Workflow App (see Capturing & Maintaining Workflows).

Identify User Roles

The Roles involved involved in each swim lane (5) should be used to identify when there is a requirement to restrict who is allowed to transition a Ticket from one workflow state to another.

These Roles are required during configuration of the end user roles that can be utilized in the Workflow App when specifying who can complete the transition (see Applying User Role Based Control).

Identify Workflow Preconditions

It is possible that some of the steps and data flows in the process model occur before the workflow to be implemented within Zendesk kicks in.

For example, an initial step might involve the prioritization and or categorization of a Ticket and the use of a workflow depends upon one or more priority values and/or categories (6).

These conditions and rules should be identified in the process model and used during the configuration of the Workflow App to determine when a workflow applies (see Specify Conditions under which a Workflow Applies).

Identify Additional Workflow Rules

Where a data flow passes between swim lanes (7) then this is an indication that there is a need to hand over control of the workflow to an alternative role player.

Also the full description of a process or step might identify the need to expose or hide one or more fields in the Ticket form, or automatically set the value of fields as part of the transition between workflow states.

This information is required when designing and implementing triggers and/or configuring additional widgets to fully implement the transitions (see Applying Additional Workflow Rules and Controls).

Planning and Preparing for Workflow Configuration

Sub Banner

Before attempting to configure the Workflow App it is recommended that the end to end process is modeled showing each of the transitions involved throughout the life cycle of a Ticket and the role responsible for performing each step.

This model can then be used to identify the various objects and properties to be captured and mapped using the Workflow App.

Design each Workflow using a Process Model

The name of the Process Model (1) corresponds to the name of the Workflow configured in the Workflow App.

Identify Workflow States

The flows between the processes in a swim lane diagram (2) indicate when there is a change in the state of the Ticket within the workflow,

The name of each process (3) provides an indication of the transition that has taken place and from which the name of each state should be derived.

These names will be required during the configuration of the Workflow App to populate the list of states to be used in each workflow (see Configuring States for use within Workflows).

Identify Workflow State Mappings

Having identified the state names, the data flows and decisions (4) can be used to determine the order and sequence of each state, i.e. when in a particular state, which of the workflow other states could follow next.

This information will be required when configuring the sequence and order of the state transitions within each workflow using the Workflow App (see Capturing & Maintaining Workflows).

Identify User Roles

The Roles involved involved in each swim lane (5) should be used to identify when there is a requirement to restrict who is allowed to transition a Ticket from one workflow state to another.

These Roles are required during configuration of the end user roles that can be utilized in the Workflow App when specifying who can complete the transition (see Applying User Role Based Control).

Identify Workflow Preconditions

It is possible that some of the steps and data flows in the process model occur before the workflow to be implemented within Zendesk kicks in.

For example, an initial step might involve the prioritization and or categorization of a Ticket and the use of a workflow depends upon one or more priority values and/or categories (6).

These conditions and rules should be identified in the process model and used during the configuration of the Workflow App to determine when a workflow applies (see Specify Conditions under which a Workflow Applies).

Identify Additional Workflow Rules

Where a data flow passes between swim lanes (7) then this is an indication that there is a need to hand over control of the workflow to an alternative role player.

Also the full description of a process or step might identify the need to expose or hide one or more fields in the Ticket form, or automatically set the value of fields as part of the transition between workflow states.

This information is required when designing and implementing triggers and/or configuring additional widgets to fully implement the transitions (see Applying Additional Workflow Rules and Controls).

Planning and Preparing for Workflow Configuration

Sub Banner

Planning and Preparing for Workflow Configuration

Before attempting to configure the Workflow App it is recommended that the end to end process is modeled showing each of the transitions involved throughout the life cycle of a Ticket and the role responsible for performing each step.

This model can then be used to identify the various objects and properties to be captured and mapped using the Workflow App.

Design each Workflow using a Process Model

The name of the Process Model (1) corresponds to the name of the Workflow configured in the Workflow App.

Identify Workflow States

The flows between the processes in a swim lane diagram (2) indicate when there is a change in the state of the Ticket within the workflow,

The name of each process (3) provides an indication of the transition that has taken place and from which the name of each state should be derived.

These names will be required during the configuration of the Workflow App to populate the list of states to be used in each workflow (see Configuring States for use within Workflows).

Identify Workflow State Mappings

Having identified the state names, the data flows and decisions (4) can be used to determine the order and sequence of each state, i.e. when in a particular state, which of the workflow other states could follow next.

This information will be required when configuring the sequence and order of the state transitions within each workflow using the Workflow App (see Capturing & Maintaining Workflows).

Identify User Roles

The Roles involved involved in each swim lane (5) should be used to identify when there is a requirement to restrict who is allowed to transition a Ticket from one workflow state to another.

These Roles are required during configuration of the end user roles that can be utilized in the Workflow App when specifying who can complete the transition (see Applying User Role Based Control).

Identify Workflow Preconditions

It is possible that some of the steps and data flows in the process model occur before the workflow to be implemented within Zendesk kicks in.

For example, an initial step might involve the prioritization and or categorization of a Ticket and the use of a workflow depends upon one or more priority values and/or categories (6).

These conditions and rules should be identified in the process model and used during the configuration of the Workflow App to determine when a workflow applies (see Specify Conditions under which a Workflow Applies).

Identify Additional Workflow Rules

Where a data flow passes between swim lanes (7) then this is an indication that there is a need to hand over control of the workflow to an alternative role player.

Also the full description of a process or step might identify the need to expose or hide one or more fields in the Ticket form, or automatically set the value of fields as part of the transition between workflow states.

This information is required when designing and implementing triggers and/or configuring additional widgets to fully implement the transitions (see Applying Additional Workflow Rules and Controls).