Servicely Configuration
Workflow
13 min
servicely provides the ability to create complex custom workflows true left unhandled content type left unhandled content type left unhandled content type left unhandled content type left unhandled content type left unhandled content type left unhandled content type left unhandled content type left unhandled content type left unhandled content type left unhandled content type left unhandled content type left unhandled content type left unhandled content type left unhandled content type left unhandled content type left unhandled content type left unhandled content type left unhandled content type left unhandled content type left unhandled content type left unhandled content type left unhandled content type left unhandled content type left unhandled content type left unhandled content type left unhandled content type left unhandled content type left unhandled content type left unhandled content type left unhandled content type left unhandled content type left unhandled content type left unhandled content type left unhandled content type left unhandled content type left unhandled content type left unhandled content type left unhandled content type implementation specifics user action the user action workflow activity provides the ability for end users to control the workflow, by presenting the the user with multiple options to progress the workflow status adding transition options press the ‘add new transition’ button, an enter the new transition name a transition can run a before script for purposes such as making a field to be mandatory before the status transition can take place an example is, to make the assignee field on incident table before moving the incident off from new to work in progress status you would code something like below you will need to end the before script with a return true; statement, so that the rest of the form checks can run to completion linking to next activity drag from the circle in the transition to the left most corner of the target workflow activity approval this activity requests approvals and will stop the records running the workflow from proceeding any further what you can configure true unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type scriptable activity the ‘scriptable’ activity allows the workflow author to run arbitrary code this activity is typically transient and does not have a workflow status associated with the activity script context the ‘scriptable activity’ receives the following script context items item description current a tablerecord object representing the object associated with the workflow context a plain json map object which can be used to store state associated with the workflow log a script logger that allows logs to be written to the workflowhistory log scriptable async activity the ‘scriptable async’ activity allows the workflow author to run arbitrary code usage is similar to the ‘scriptable activity’ with the primary difference being that this activity is designed to be used when the result of the script is asynchronous (i e the activity needs to wait on something external happening) this activity creates an associated workflow status the scriptable async activity exposes two scripts an initialization script and an evaluation script the initialization script is called once when the activity is initiated, and is designed to be used to perform any initialization associated with the activity (initiate an integration, raise subtasks, etc ) the evaluation script is called asynchronously to determine whether the activity has completed this needs to be performed by an external action (e g on completion of an integration) a convenience method is available to automatically evaluate paused workflows for related tickets (e g for subtasks or other related information) table property description example workflow\ trigger parent field a table property that specifies a relationship that will trigger an asynchronous workflow evaluation of the related record can also be a comma delimited list of relationships on the hrcasetask table, specifying the value “parenthrcase” will enable the evaluation of the workflow related to hrcase records script context the ‘scriptable async activity’ receives the following script context items item description current a tablerecord object representing the object associated with the workflow context a plain json map object which can be used to store state associated with the workflow log a script logger that allows logs to be written to the workflowhistory log activityoptions constants used for the return value or other items within the script scriptable async actions that have not yet completed their requirements should return the value activityoptions delay evaluation scriptable async actions that have completed their requirements should return true execution order when there are multiple workflows for the same table, e g itsm request table having multiple workflows for different catalog items, please ensure that they are ordered accordingly this is necessary for the use case where the workflow is attached to the table not because of service catalog, e g raising itsm request directly when a record such as itsm request is directly created, servicely will select the workflow with lowest order number this means a workflow with order of 10 will take precedence over the one with order of 20