Learn by Example

This page provides some basic examples for Core Workflows. Of course you can build much more complex workflows if needed.

To learn about Core Workflows in detail, first go to How do they work?.

Group Based Examples

All following workflows have the same base configurations. The workflow may not use them all.

  • Groups:

    • Sales

    • Support

    • 2nd Level

  • Attributes:

    • Category (Single tree selection field, not mandatory, agents only)

    • Approved (Boolean field, not mandatory, not shown, false as default)

    • Operating System (Text field, not mandatory, not shown)

    • Software used (Single selection field, not mandatory, not shown)

  1. Group specific values and fields

    This workflow set depends on the category field. It reduces the available set of values based on the group selected.

    This reduces the category options to 2nd Level/*, Internal/* and Others. It also sets further required fields to mandatory and visible.

    Sample workflow that shows specific values and fields for 2nd level
    The Result

    This is what the agent would experience with the above workflows in place.

    Workflow shows objects and limits options based on selections on the group
  2. Approval process

    In this case approved is visible to agents by default. For this workflow, an additional role Approval person is required (no further permissions).

    Sample workflow that restricts an approval attribute to specific roles

    Tip

    This workflow may work best in combination with a trigger but technically, this is not required.

    Select fields may be a better approach because they allow more values than just a simple true or false.

    The result
    Workflow fixes possible values of "Approved ?" to a specific selection depending on the users role
  3. State dependent mandatory fields

    This workflow sets Category to mandatory if the agent wants to set the states closed or pending close to enforce categorization.

    Sample workflow that sets fields to mandatory on specific states
    The result
    Workflow sets category field to mandatory upon choosing closed or pending close as state

Manual Ticket Handover Process

This example covers the handover of a ticket from one agent to another:

  • When the ticket owner is modified, a new text field (“Handover”) shows up for a comment

  • This may only be visible when the owner is changed, therefore it has to be hidden in general

  • The input in this handover text field is mandatory

  • After submitting changes, the value of the handover field must be added as an note to the ticket (via trigger)

Hiding handover field
Hiding the handover field in core workflows
Showing handover field and setting it to mandatory
Showing the handover field and set it as mandatory
Trigger writing handover input to a new article
Write handover content to a new article

As a result, the ticket includes an article of the type note which includes the predefined text and the handover comment.