Introducing Task Boundaries

Introducing the new Task Boundaries feature in V9.0.x

In prior versions, some workflow behavior was determined at run-time (rather than design-time) based on the user performing a step and the step assignment. It was hard for the designer to predict workflow behavior because of the possibility of different combination of users/assignments that may result in a screenflow vs. a standard workflow. 

In v8.0 and prior, these errors in flow design would be apparent in certain use cases such as:

1) The second step (i.e. Manager Approval) on a Vacation Request workflow was set to the template reports.to() which resolved to a manager's name. If the manager user was not configured correctly so that this template resolved to null, the user who performed the first step would automatically get a screenflow for the next step and could approve their own vacation request.

2) A company used a launcher form to launch another flow, such as a budget request, by sending the first step of a flow to a specified user's task list. If the first step was a template that resolved to the same userId of the person running the launcher form, it would become a screenflow rather than putting that step on their task list. 

3) A Sales Order Form used the Anonymous Step feature to send an order form to a client. The salesperson wanted to access the task and reject it back to the first step to make a correction, but if the salesperson performed the anonymous step, that step would become a screenflow and the the reject button was not enabled. 

In v9.0, the designer now defines workflow behavior at design time using task boundaries. Task boundaries are created by setting assignments (user, role or email address), so each flow step with an assignment is considered a new task. Any subsequent flow steps without assignment are considered part of screen flow of the same task. This diagram illustrates how designers can manage task boundaries and workflow behavior:

To preserve the convenience of a screenflow, if the next step is a new task and the current user is eligible to perform it, a message will appear with a link to continue the flow in the same screen. When the user clicks the link provided, the flow will continue like a screen flow but a new task will be created behind the scenes. 

When navigating back using the navigation bar, consecutive unassigned tasks in a screenflow will be available to edit. Once a user has moved on to a subsequent assigned step, all prior steps will be read only.

When a task that is routed to templatized user, role, or email resolves to null or empty string, instead of becoming a screenflow, the task will now be assigned to the "invalid-task-assignment" userId and a notification with be sent to flow admin users (or tenant admin user if no flow admin is configured.) This will enable flow admin users to easily search mis-routed tasks assigned to the "invalid-task-assignment" userId and re-assign to valid user.

Having an assignment to a flow step strictly enforces the task boundary and it is applicable for the first step of flow as well. This means to create a task for the first step there is no need to explicitly configure the Task for First Step property, so this property has been removed. Instead, configure the first step with an assignment.

Click here to learn how this will affect existing flows.

This improvement in v9.0 helps designers direct workflow behavior by using step assignments to enforce task boundaries. It effectively prevents workflow design bugs from becoming runtime bugs, such as in the case of an employee inadvertently approving their own PO or vacation request.

We appreciate you trusting frevvo with your mission critical applications. It is our goal to always provide you with the highest quality of service possible.

Thanks,

frevvo Customer Support