Loopbacks, Sub Workflows and Milestones in the Content Server Workflow
Here we handle a few other things on a Content Server Workflow.
First, lets do an example
Example workflow: Reiners Party Request
We want to get a party during this workflow.
Create a Workflow Map by adding a Workflow at your favorite location. Lets call it Reiners Party
To see the workflow Designer, press Edit
This is the workflow Map
Loopbacks
Many business processes contain steps or procedures that need to be repeated. Loopbacks are workflow paths that repeat a section and appear on the Workflow Map as blue lines. Loopbacks may originate or terminate at any kind of step except a Start step. Workflow authors may also nest loopbacks as many levels as they like.
The rules for Content Server loopbacks are straightforward and workflow authors will get an error message if their loopback does not follow Content Server logic.
Here the general rules:
Dates
In Content Server, workflow authors can assign dates and priorities to the workflow and its steps to define when work is to be completed. They may then specify a task priority and the time in days and hours that this user has to perform the task before it receives a late status.
Due dates can be re-calculated and this option is useful when they want to re-adjust the due date for remaining steps when the current step is completed.
Also Step and workflow timings can be considerted.
Step Late Each step in the workflow can have a specified duration in days or hours. If that duration is exceeded, then the workflow status becomes Step Late.
Workflow Late Content Server can calculate an overall workflow due date programmatically when a workflow is initiated from the map. When the duration of all the steps has been exceeded, then the status will change from Step Late to Workflow Late.
Milestones Workflow authors can set specific due dates as milestones. If the date specified in the milestone has passed by the time the workflow reaches the milestone, then the workflow status becomes Milestone Late.
If the calculated workflow due date is not useful (which can happen if a workflow has the potential for many loops or branches), then the workflow author can allow the Initiator to enter a specific workflow due date from the start step. If that date expires before the workflow is complete, then the workflow is assigned a status of Workflow Late.
Workflow authors may select the Skip weekends in due date calculations option so that Saturday and Sunday are ignored when calculating due dates. This option is useful if the workflow author is using step durations and do not want to include weekends.
Milestone Step
Lets add a milestone step named as Party Milestone:
Milestones can be useful markers in a workflow – when they are passed events are added to the workflow audit trail. Workflow authors can also use milestone due dates to help drive the workflow by defining a specific milestone due date or letting Content Server calculate the due date. For a milestone to be accurate, due dates must be included for all steps leading up to the milestone.
In order to branch a workflow based on a status of Milestone Late, the milestone must come after the Evaluate step. This is because Milestone Late is the status of the whole workflow and not a single step. Once that milestone is passed, the Milestone date due depends on the next Milestone step. While placing the milestone after the Evaluate step is not intuitive, it is logical as it allows workflow authors to have multiple milestone steps throughout the workflow. When one milestone step is passed, the next one determines the status value.
A doubleclick on the Miltstone reveals the menu:
Test it
Initiate the workflow.
It will display in smartUI
Start the workflow
Supply the comments
Recommended by LinkedIn
Sub-Workflows
Lets add a subworkflow
and as Sub-Workflow
In the Reiners Party workflow, a double click on Sub-Workflow reveals the Menu
Enter a name in the Initiate As field for the initiated Subworkflow. Otherwise, the Sub-workflow will initiate with its own default name.
When you define sub-Workflow steps, you must specify the following information:
General information, which includes the step name, the Workflow Map you want to embed, an initiate name, duration, and date calculation preference.
Data availability and mappings, which determines how work package information, such as comments, attributes, and attachments, and other data are shared between the main Workflow Map and the Workflow Map you are embedding.
Specifying General Information
The general information you can specify for a Sub-Workflow step includes this steps:
The step name.
The Workflow Map you want to embed in the main Workflow Map. The name assigned to an instance of the sub-Workflow when it is initiated.
The amount of time (duration) in which you want the sub-Workflow to be completed (in days or hours).
Whether Content Server should recalculate the Workflow Map due dates after the step is completed.
Specifying Data Availability and Mappings
You must specify how the work package and other main Workflow Map data is shared with the embedded Workflow Map.
Example
If the main Workflow Map contains an attribute named Title and the sub-Workflow uses an attribute called Document Name, you can create a mapping between the attributes so that the value from the main Workflow Map is available in the embedded Workflow Map attribute. The embedded Workflow Map can modify the attribute value.
Depending on the information enabled in the Workflow Map package, you can specify the availability and mappings for the following information types:
Exchanging Role
If the main and embedded Workflow Maps use roles, you can specify how a role in one Workflow Map corresponds to a role in the other by creating a role mapping. For example, if the main Workflow Map contains a role named Manager and the embedded Workflow Map has a similar role named Leader, you can create a mapping between the two roles.
All roles in the main Workflow Map must be mapped to a role in the embedded Workflow Map.
Exchanging Comments
You can control whether participants in the main and embedded Workflow Map can view the comments made in either Workflow.
Exchanging Attributes
You can map attributes in the main Workflow to attributes in the sub-Workflow so that attribute values pass between the two Workflow Maps. When the sub-Workflow ends, the values of its mapped attributes pass back to the main Workflow Map.
When you map attributes, the data type of each attribute in the main Workflow Map must be compatible with the data type of the sub-Workflow attribute to which you map it. The sub-Workflow must also have at least one defined attribute type.
Exchanging Attachments
If you want participants in the embedded Workflow Map to have access to the attachments in the main Workflow Map, Content Server creates a Shortcut to the Attachments folder of the main Workflow Map in the Attachments folder of the embedded Workflow Map. Items placed in the folder represented by the Shortcut during the embedded Workflow Map processing are accessible from the main Workflow Map; items outside the folder are not available in the main Workflow Map. If you select individual items, Content Server creates a Shortcut in the Attachments folder of the embedded Workflow Map.
An efficient way to organize the attachments exchanged between Workflow Maps is to create a folder that will contain only those attachments to be exchanged in the Attachments folder of the main Workflow Map, and then make that folder available in the embedded Workflow Map.
Exchanging Forms
You can map Form fields in the main Workflow Map to Form fields in the sub-Workflow so that field values pass between the two Workflow Maps. When the sub-Workflow ends, the values of its mapped fields pass back to the main Workflow Map.
