Understanding Service Portal Workflow

Service Owners and Space Admins can create custom workflows (or processes) to meet any of their business needs or leverage pre-built, common workflows to get up and running quickly.

Pre-built Workflows

Pre-built workflows allow Service Owners to configure the following options:

• A single approval assigned to the submitters Manger, a Specified User or a Team
• A single fulfillment task assigned to a Team or a specific User in a Team

To learn more about leveraging pre-built workflow and the configurations that drive that workflow, see the Configuring A Service article.

Custom Workflows

Custom Workflows allow Service Owners and Space Admins to create tailored processes for their Services. Common custom workflows include:

• Multiple Approvals
• Multiple Fulfillment Tasks
• Approvals after a Fulfillment Task is completed
• Integrations to Other Systems

Custom Workflows are configured in the Kinetic Task Admin area, and then attached to a Service in the Service Settings area.

Custom trees are created with a specific name that will run when a service is submitted, like this one for on-boarding:

The names of each workflow are important because they dictate when the workflow is supposed to be run and what variables will be available to workflow builders when creating one. All workflows have a Source a Source Group and a Name. There are a few important items to know when creating your own workflows:

• The Source field when creating a workflow is typically "Kinetic Request CE" for workflow that needs to run when something happens within Kinetic.
• The Source Group field ties the workflow to a specific object within the system and follows a very specific naming convention.
  • For Submissions, the naming convention is Submissions > yourKappSlugHere > yourFormSlugHere (Ex Submissions > services > employee-onboarding would be the Source Group of the workflow attached to Submissions in the Employee Onboarding Form in the Services Kapp)
• The Name field ties the workflow to a specific action that happens on an object within the system.
  • Created Workflows that are meant to run when the object in the Source Group is created. (Ex: A workflow with the Source Group Submissions > services > employee-onboarding and a name of Created would run when a Submission (Service Request) is created by a user. In Kinetic, Users can create a new request and save it (without Submitting it). You may want to create a workflow that sends a reminder to the User to Submit it after a few days and would use a Created workflow to do that.
  • Submitted Workflows that are meant to run when the object in the Source Group is submitted. (Ex: A workflow with the Source Group Submissions > services > employee-onboarding and a name of Submitted would run when a Submission (Service Request) is submitted by a user. This is the most popular workflow type for submissions and is typically where you would put your fulfillment logic.

To attach the custom workflow to the actual service so that it runs when the cooresponding action happens, services must have the attribute: Submission Workflow set. For create workflows it would be "Created - True" and for submit workflows it would be "Submitted - True".

All workflows are built using the Kinetic Task portion of the platform, but there are a lot of preconfigured trees and routines for you to take advantage of. You should be able to build your workflows by piecing together these building blocks with relative ease.

There are detailed follow-up articles on each of these key routines:

• KD route approval: This routine allows you to create any type of approval.
• KD Task: This routine allows you to create and assign a fulfillment task using any fulfillment form.
• KD Notification Send Using Template: This routine allows you to send a notification to an user, team, or email address using the notification templates.
• KD Discussion Create: This routine allows you to create a discussion.
• KD Update Submission Status: This routine updates the status of the user's request (or another submission if provided).

There are many other routines (or building blocks) for you to leverage as well, if desired.

You may notice there are some terminology changes when you switch between the Solution and the Platform. Here is a helpful guide of equivalencies to get you started:

• Request == Submission
• Workflow == Tree/Routine
• Service == Form