Business processes can include one or more workflows to specify how a BP should proceed from start to finish. This chapter explains how to design the workflows that are part of business processes and other components that will be used by the users in Primavera Unifier.
Workflows are optional.
About Workflows
Workflows illustrate each step in a business process, and each step will utilize the forms that you have created in uDesigner. Like business processes, you can create workflows at both the shell/project and company levels (see Designing Process Functions at These Levels).
Workflows define how forms are routed and govern the behavior of each step in the business process. Using uDesigner, you will be creating the workflow schemas—the flow of business process steps and the forms the users will use at each step.
In Primavera Unifier, the administrator will fill in the workflows with the who, what, where, and when information for each business process, and users will fill in the forms with the information they will need to run the project, such as maintaining action items, managing document archiving, tracking workflow tasks and milestones, communicating and collaborating with project team members, and generating project reports.
Non-workflow BPs
Most business processes will include one or more workflows; however, some business processes have a single purpose of storing data. These business processes are called non-workflow BPs. An example of a non-workflow BP is one or more forms that record contact and other general information about a company. Non-workflow BPs are editable after the form is complete, unless you place a terminal status on the form at completion.
Overall Steps for Workflow Design
It is important that you design your workflows on paper before designing them in uDesigner. Workflows will often need modifying before they satisfy all the requirements of a business process.
Once you design the workflow for a business process in the Development environment, Oracle recommends that you do not delete the workflow, as it may cause unexpected results in Unifier. You can, however, deactivate your workflow in the Development environment, and then republish the business process with a new workflow.
Overall steps for designing a workflow
- Name the workflow.
- Add the workflow steps.
- Specify each step's properties.
- The name and description of the step
- Any read-only forms that are available to the recipient at this step
- Any action item forms the recipient must respond to at this step
- Link the steps.
- Specify each link’s action (such as send, reject, or approve).
- Specify the status the task should be in after the team member completes the action (such as approved, rejected, or closed).
- Group any sub-workflows (if any).
- Add conditional steps (if any).
Specify the step properties, including any situation at this step that might trigger a conditional step that must be resolved before the workflow can continue.
For designing a successful workflow, follow these instructions:
- Create all the action and view forms of a business process before you design the workflow.
- Be mindful that every action in a workflow creates a potential email notification. The fewer steps, the better.
- Do not recycle actions to users unnecessarily.
- Use multiple-approver steps rather than serial approvals whenever possible.
- For the workflow steps, use a noun, such as Customer Approval or Finance Review.
- For the links between steps, use a verb that designates the action being taken, such as Send Back for Clarification or Reject.
- If a step’s inbound action has a terminal status, then all outbound actions from that step must have the same terminal status.
- For a business process with multiple workflows, use the same form for the end step of each workflow. This ensures that the same final form will be generated each time a BP record is complete, regardless of the workflow that is used.