Designing a workflow

Designing a workflow involves knowing your business, understanding the workflow process, planning the workflow, planning the workflow participants, and designing the task views.

Know your business

Before you design a workflow, study the business process that the workflow is modeled on. Make sure you understand every step in the process and what each person or department must accomplish. Ensure that you have a clear grasp of the business process before you get started. Make sure you also know who needs to approve your design and how the approval process works. You will want to share your design with the stakeholders and make revisions based on their input.

Plan the workflow process

After you understand the business process, plan the design of the workflow. You likely have several ways you can approach it. Look at the pros and cons of each approach before you proceed.

  • What is the driver for the workflow? Do you need multiple workflows or can you use one workflow and apply conditions on Applicability in the workflow properties? For example, is there a different workflow based on values in the object?
  • How large is the workflow? You can break a large workflow into multiple smaller workflows. To link workflows together, you define actions that start workflows for related objects and end stages that start workflows for the same object. Add validation to make the workflows dependent on each other based on specific circumstances or results.

    Take care that you do not create a situation where workflows go into an infinite loop and overload the system. For example, you can inadvertently create a cascading effect when one workflow starts 1000 workflows, each of those 1000 workflows start another 1000 workflow, and so on. Safeguards are in place to avoid such a problem but they do not cover all possibilities.

  • Does the workflow start automatically or manually?
  • Does the workflow start on a set schedule?
  • How many stages are there? Each stage creates a task.
  • What needs to happen each time the stage changes? What validations need to occur at every stage change? What operations need to happen? Do fields need to be set or values calculated?
  • What stages in the workflow do you want to allow users to complete as bulk workflow actions? For these stages, users can access tasks from the Complete task with bulk workflow actions window. It allows users to more quickly and efficiently work through the tasks they must complete.
  • What are the options on the Actions button? What conditions must be met for an option to display? If options on the Actions button are displayed only to specific users, add text to the user guidance so that other users understand why no options are visible to them.
  • Can a user provide a comment when they complete an action? If so, is the comment optional or required? For example, the rejection action on an approval stage can be defined to require the user to enter a comment. You can configure comments for all actions in a workflow except the initial action, which is from the start stage to the first standard stage. Plan how you want to use comment information and make it visible to other users. The workflow system fields for comment text, comment owner, and comment date can be included in task views and email notifications.
  • Plan how often users receive email notifications in the workflow. Email notifications can be sent every time the stage changes and when a workflow ends. Plan the email notifications so that users are informed but not overloaded with emails.
  • Plan when users receive email reminders. Emails reminders can be sent on a repeating schedule relative to a stage's due date. Plan the email reminders so that they effectively help users get their work done. Email reminders are sent as a summary email, which means that a user receives one email per day regardless of the number of tasks that generated a reminder.
  • Are there points in the workflow when another workflow for a related object needs to start?
  • Are there points in the workflow when child objects need to be created?
  • Are there any points in the workflow when a calculation needs to be run?
  • What are the cancellation or rejection paths in the workflow? At what point can a user cancel a task and what stage does the cancellation take them back to? What fields that were set by a field now need to be cleared? If an assignee must go back, how much work do they need to repeat? Plan paths in the workflow in both a forward and backward direction, as your business process requires.
  • How many ways can the workflow end? You can define multiple end stages if a workflow can end in different scenarios. For example, you might have a workflow that can end in one of three ways.
    • End stage A: the workflow finishes successfully and fields 1, 2, and 3 on an object are set to the values A, B, and C.
    • End stage B: the workflow finishes successfully and fields 1, 5, and 6 on an object are set to values B, Z, and Y.
    • End stage C: the workflow is canceled and no actions are taken.
  • Who needs to receive an email notification when a workflow ends? The oversight user and any other users you designate can receive an email notification when a workflow ends.
  • Is the object finished when the workflow ends or does another workflow for the object need to start?
  • What workflow information needs to be retained after the workflow finishes? After a workflow is finished, the workflow information on an object is no longer displayed. You need to save workflow information to objects to retain workflow information, for example, the completion date and the assignees.

Review the object structure

Understand the object structure. A workflow action that creates an object can create only a direct child object. But applicability in the workflow properties and conditions and validations on actions and the end stage can be based on field values on a related object that is a direct child, direct parent, ancestor, or descendant object.

Plan the workflow participants

After you plan the design of the workflow, map out who the workflow participants are.

  • Who can start the workflow? You can restrict it by applying conditions on Applicability in the workflow properties.

    The user who starts a workflow is saved in System Workflow Fields:Workflow Start User. Conditions where you can select A field in the current object or A field in a related object can be based on the value in this field.

  • Who is the oversight user for the workflow? The oversight user is defined in the workflow properties.
  • Who are the assignees for each stage? Assignees are defined by stage. The assignee gets a new task every time the stage changes. If the assignee for a stage is a user group, the task is displayed on the dashboard and My Tasks tab for all users in the group. Any user in the group can pick up the task and complete it.

    The user who performed the most recently completed action is saved in System Workflow Fields:Last Action User. Conditions where you can select A field in the current object or A field in a related object can be based on the value in this field.

  • Who are the participants for each stage? Participants are defined by stage.
  • Who else has access to each stage of the workflow? Should users who are not workflow participants be allowed to see objects? You define access by setting the Access Type field on the stage properties.

Plan the Task Views

Workflows and task views work hand-in-hand. An existing Task View for an object type might be suitable for your workflow design or it might need slight changes. For example, if an assignee has to set a date field during a task, ensure that the date field is in the Task View. If no existing Task View is suitable for the workflow, you can create a new one.

For information about what Task View is used by a workflow, see Defining a standard stage.

You can add workflow fields to a Task View. For information, see System workflow fields.

The Actions button that is defined in an action in a workflow takes precedence over the Actions button defined in a Task View.

Consider how to use Task View Overrides per stage when you plan fields, sections, user guidance, and key fields. You can use Task View Overrides to:

  • Override whether a field is hidden or read only for a stage.
  • Hide a section in a Task View or override the Initially Collapsed setting.
  • Override the user guidance that is defined in a Task View with user guidance defined for a stage.
  • Add the key fields that are defined in the Task View Overrides on a stage to the list of Key Fields in the user guidance panel, regardless of whether the user guidance is defined in the task view or the guidance text override.

An overall design decision you may want to take is to use one Task View in many workflow stages. To do this, do not define user guidance in the Task View. Then, define highly specific user guidance in the Task View Overrides for each stage. Then you can more precisely control the user guidance that are displayed for each stage. And you have fewer Task Views to manage.

An overall design decision you may want to take is to omit key fields from the user guidance in the Task Views. Instead, define key fields in the Task View Overrides on stages. You can then more precisely control the key fields that are displayed for each stage.

Plan the Grid Views for the bulk workflow actions

If you are using the bulk workflow actions feature, determine if existing Grid Views are adequate or whether you must define unique Grid Views. For more information, see Defining Grid Views for bulk workflow actions.

Review sample workflows

OpenPages® provides sample workflows that you can as delivered or modify to meet your requirements. They can also be used as templates and learning tools for your own workflow. For more information, see the IBM OpenPages with Watson Solutions Guide.

Leverage the Preference objects

Review your organization's implementation of Preference objects. You can use Preference objects to hold entity-specific variable values that enable different behavior for different workflows.
  • The assignee can be retrieved from the Preference object.
  • The oversight user can be retrieved from the Preference object.
  • Conditions on an action can be based on a Preference object.

Review the association of Preference objects to Business Entities. If a Business Entity has more than one Preference object associated to it, even if only one is active, a workflow that references fields on the Preference objects will fail. In this situation the following error is issued: Multiple Preference objects on same entity causes workflow to fail: OP-08521. To resolve this issue, ensure that only one Preference object is associated to a Business Entity.

For more information about Preference objects, see the IBM OpenPages with Watson™ Solutions Guide.

Plan the due dates

A workflow has an overall due date and each state has a due date. For information, see Interpreting and viewing due dates.