There are a few things I always think should be considered when using a workflow.

• Patterns
• Activities
• Script

Patterns

1. Always, always add a timer after the Begin activity.
2. Avoid Switches because they don’t update when their conditioned field changes.
3. Avoid Email Activities, instead, opt for Event activities.

Here I have a diagram showing a timer added after the Begin activity. This timer returns the user’s session so it seems immediately which is great for user experience. However, it makes your workflow dependent on the events queue. If that goes down, this is the least of your worries.

    graph LR 
    S0[Begin ] 
    T1[Timer]
    R1[Run Script]
    E0[End]
    S0-->T1 
    T1-->R1 
    R1-->E0

Next, I have a Diagram showing the Switch, if some changed the variable/field values of “Standard” to “Mechanical” the workflow activity won’t know to use the new value until you check it out, then recreate the switch, and check it back in. Because of this, I use If activities. It is more activities but, because the If activities are scripted, they won’t break when you modify the variable. If activities used to allow you to create any number of “result” boxes below, one of them being an “else” but now If’s only allow yes and no for results. Below is an example Switch Workflow and it in the If pattern.

    graph LR 
    S0[Begin] 
    T0[Timer]
    S1[Switch] 
    T1[Task 1]
    T2[Task 2] 
    T3[Task 3] 
    T4[Task 4] 
    R1[Run Script]
    E0[End]
    
    S0-->T0 
    T0-->S1 
    S1--Ergonmic Split-->T1 
    S1--Ergonmic -->T2
    S1--Gaming -->T3 
    S1--Standard -->T4 
    T1-->R1 
    T2-->R1 
    T3-->R1
    T4-->R1
    R1-->E0

graph LR;
  S0[Begin];
  T0[Timer];
  I1[If Egonomic Split];
  I2[If Egonomic];
  I3[If Gaming];
  I4[If Standard];
  T1[Task 1];
  T2[Task 2];
  T3[Task 3];
  T4[Task 4];
  B1[Branch 1];
  B2[Branch 2];
  B3[Branch 3];
  B4[Branch 4];
  J0[Join];
  R1[Run Script];
  E0[End];

  S0-->T0;
  T0-->I1;
  T0-->I2;
  T0-->I3;
  T0-->I4;
  I1--No -->B1;
  I1--Yes-->T1;
  I2--No -->B2;
  I2--Yes-->T2;
  I3--No -->B3;
  I3--Yes-->T3;
  I4--No -->B4;
  I4--Yes-->T4;
  T1-->B1;
  T2-->B2;
  T3-->B3;
  T4-->B4;
  B1-->J0;
  B2-->J0;
  B3-->J0;
  B4-->J0;
  J0-->R1;
  R1-->E0;

Last but not least, because I think you should avoid checking out workflows, always use events in workflows if you need a workflow to generate a notification. There are some additional steps to take to do this but it’s well worth it because now you can use the notification records how they are for the rest of the system, you can generate the notification without the workflow by running the following in a business rule or any server-side script;

gs.eventQueue('custom.notification', current, 'parm1', 'parm2');

Now if you were using variables and are not sure how to pass more than two parameters, don’t fear. Just make your first parm a JSON.stringify object. Sure you’ll need to JSON.parse the object in the notification, but now you can pass everything in a way not dependent on the workflow.

Activities

Parallel Flow Launcher

Launches multiple subflows in parallel.

A few things;

• You MUST specify a count, without it, you’ll get an error.
• If you want to get an output from a subflow, in hte Flow complete script you can access it via flow.output
• flow.output requires the subflow has Return activity.

Branch

The offical use of this is “Splits the workflow into multiple transition paths from a single activity.”

I like to use this to keep my lines clean.

Join

Unites multiple execution paths into one transition.

Generally I remove the “incomplete” transistion off of the activity. Also, ALL activities connecting TO this must complete.

Return Value

Returns a value to a parent workflow, when run from a subflow.

Run Script

Runs the specified script in the scope of the workflow version.

This activity is ver versitile. You can add transisitions based on values you set in the scratchpad and then have those go off. This is a great replacement for;

• Attachment Note
• Soap Message Legacy
• Rest Message Legacy
• REST web service
• SOAP web service

Set Values

Sets values on the current record when the workflow quiesces or ends.

If

Checks a condition or script to determine if a Yes or No transition should be taken.

Approval Action

Performs an approval action on the current task.

Approval Coordinator

Creates an approval whose outcome depends on the outcome of one or more child activities.

Approval - Group

Creates approval records for each member of a specified group.

Approval - User

Creates one or more individual user approvals.

Manual Approvals

Watches and manages any approvals that users add manually outside of the workflow process.

Catalog Task

Creates a service catalog task record. These records are associated to the workflow via the wf_activity field.

Create Task

Generates a record on any of the tables that extend Task [task]. These records are associated to the workflow via the wf_activity field.

SLA Percentage Timer

Pauses the workflow for a duration equal to a percentage of an SLA.

Timer

Pauses the workflow for a specified period of time.

This should be added to the begininng of every workflow to have the workflow run on it’s own thread.

Create Event

Adds an event to the event queue, but does not immediately fire the event.

Script

initialize

Method called by the Prototype JavaScript Framework during object construction.

startFlow

(workflowId, current, operation, vars) Starts a specified workflow.

startFlowFromContextInsert

(context, operation) Helper method for business rule “Auto start on context”.

startFlowRetroactive

(workflowId, retroactiveMSecs, current, operation, vars, withSchedule) Used by the “Start Workflow” business rule on table task_sla to start a workflow. ## runFlows

(record, operation) Runs all workflows for a given record in a given table and its descendant tables. ## getReturnValue

(workflowId) Gets the appropriate workflow return value for the input workflow ID. ## getVersion

(workflowId) Gets the appropriate workflow version for the input workflow ID. ## getVersionFromName

(workflowName) Gets the appropriate workflow version for the input workflow name. ## getWorkflowFromName

(workflowName) Gets the appropriate workflow for the input workflow name. ## hasWorkflow

(record) Determines if a specified record has an associated workflow. ## fireEvent

(eventRecord, eventName) Fires the named event on the input record. ## fireEventById

(eventRecordId, eventName) Fires the named event on the record specified by record ID. ## broadcastEvent

(contextId, eventName) Broadcasts the named event for the specified context ID. ## cancel

(record) Cancels any running workflows for the document.

cancelContext

(context) Cancels the specific running workflow context.

getRunningFlows

(record) Gets the running workflow contexts for a specified record.

getContexts

(record) Gets the workflow contexts for a specified record whether it is running or not.

restartWorkflow

(current, maintainStateFlag) Restarts the workflows associated with a GlideRecord.

deleteWorkflow

(current) Deletes all workflows associated with a specified GlideRecord.

sortStages

(versionID) Not implemented.

getEstimatedDeliveryTime

(workflowID) Gets the estimated time for a workflow to complete.

getEstimatedDeliveryTimeFromWFVersion

(wf_version) Gets the estimated time for a workflow to complete.