19 Creating and Managing Workflow Processes

With the workflow feature of WebCenter Sites, you can route assets through whatever series of tasks you deem necessary in a workflow process from creation to approval. These tasks may be many or few as required. Through workflow management, you can manage an asset with multiple contributors efficiently.

For example, if assets of a certain type must be reviewed by an editor or a legal representative before it can be approved for publishing, the workflow feature can route those assets to the appropriate people at the appropriate time.

About the Workflow Feature

The end goal for any content provider is to have content assets published. Before an asset can be published, it must be approved for publishing. The workflow feature routes assets through whatever series of tasks you deem necessary in a workflow process that ushers assets from creation to approval.

You can configure a workflow process with as many or as few tasks as necessary to reflect the way the work at your organization is accomplished. You can configure email messages that WebCenter Sites sends to notify people when assets are assigned to them and to remind them that a deadline is approaching or has been missed.

Because there are so many configuration possibilities, it is typical to create a separate workflow process for each asset type that you plan to use workflow with rather than attempt to create one process for multiple asset types.

For more information about the workflow feature, see the following topics:

Understanding Workflow Participants

The job titles of the people who participate in a workflow process are considered roles in the interfaces. Roles describe the function of an individual on a site. When you enable a user for a site, you assign that user the roles that he fulfills for that site.

When you create a workflow process, you determine which roles are appropriate for each task. Then, when an individual asset is going through that workflow process, only the users who have the appropriate role are allowed to complete the task. The individual user who is selected from the pool of users who have the correct role at any point is called a workflow participant.

Understanding Workflow States

Tasks performed on assets are called workflow states. A state is a point in the workflow process that represents the status of the asset at that point. For example, writing article, reviewing image, legal review, and so on. Participants complete the work that the state represents while the asset is in that state.

The movement of an asset between states is called a step. Creating the steps in a process links together states in a specific order, and creating the steps in your workflow process is what organizes your process.

An asset that a participant is working on is called an assignment. A user's assignment list is shown In the My Assignments form in the administrator's interface. Assets are assigned to users as soon as it enters a state the user to fulfills as workflow participant.

Assign a deadline to the state to keep the asset in that state for a specific amount of time. You can configure the workflow process to send email messages that remind a participant when the deadline is approaching or missed. These email messages are examples of timed actions. You can create one or more timed actions for each state.

Moving Assets from State to State

When you create a step in a process, you specify which state a step moves the asset from (the From State), which state that step moves the asset to (the To State), and which roles can take the step.

A step places an asset in a state and notifies participants from the appropriate roles. This operation creates the assignment. You then have a step for the participants from those roles to take that moves the asset to the next state. In other words, the roles notified by the previous step should be the roles authorized to take the next step. For example:

When a user selects the Finish My Assignment option for an asset that is assigned to him or her, that option calls the step, moves the asset to the next state, and assigns the asset to the next participants. When multiple participants are assigned an asset in the same state, using the Finish My Assignment option is also referred to as voting. Each participant votes to move the asset to the next state.

The first step in a workflow process is a start step. A start step has no From state. That is, the start step begins the workflow process, moving the asset to the first state in the series of states. This is the step that is called when the workflow process is assigned to the asset. Only users who have the roles authorized for the start step can start the workflow process for an asset.

Step actions are events that occur when the step is completed. You can specify one or more step actions for each step. An example of a step action is the ApproveForPublish action. It is a default action delivered with that approves the asset. Typically you use this action in the final step of a workflow process.

Working with Multiple Paths for the Asset

When a workflow process includes a state where people review an asset, typically there are multiple paths possible for an asset in that workflow because the reviewer can either accept it the way it is or reject it.

In these cases, you create two steps for moving the asset from the review state. When the asset is in that state, the Finish My Assignment form lists both options and the participants select the appropriate step when they finish their assignments.

If multiple participants are reviewing the same asset in the same state and they choose different steps, what happens depends on how you configured each step. There are several possibilities:

  • Configure the steps so that the first participant to finish the assignment (vote) determines the direction the asset takes.

  • Configure the steps so that all participants have to select the same step (vote the same way) in order for the asset to progress in either direction. A step that all the participants must select before that step can be completed is called an all-voting step. Note that this option can result in deadlocks.

  • Use a combination of the preceding possibilities: configure one all-voting step (all participants must agree), and configure the other step(s) so that if any participant selects it, the step completes and the asset takes that path.

Managing Deadlocks

A deadlock occurs when the following conditions are true:

  • There are multiple steps from a state.

  • Two or more of the steps require the participants to perform that step. That is, they are all-voting steps.

  • An asset in that state is assigned to multiple participants.

  • The participants select different all-voting steps when they finish the assignment.

The following figure illustrates a deadlock.

Figure 19-3 Deadlocked Workflow

Description of Figure 19-3 follows
Description of "Figure 19-3 Deadlocked Workflow"

Note that if even one step is not all-voting and a participant selects that step, the asset will not become deadlocked.

An asset that is in a deadlocked state cannot progress through the workflow process until the deadlock is resolved. To resolve the deadlock, the participants must confer with each other and agree on that path that the asset should take. Then, the participants who must change their selection can do either of the following to resolve the deadlock:

  • Finish the assignment and select the step that they all agreed to take.

  • Select the Abstain from Voting option from the Workflow Commands drop-down list on the asset's Status form.

Before configuring a workflow process that can result in a deadlock, be sure that it is absolutely necessary to have complete agreement on all the possible steps from the state. As you can see from this description, deadlocks cause additional work for all the participants so be sure that you use this feature only when you have to.

For example, consider a review state with two possible steps: "return for revisions" and "approve for publish." If you configure the steps so that "return for revisions" does not require a unanimous vote but "approve for publish" does, you have created a desirable control—all the reviewers must agree before the asset can be published and any rejection stops the asset from being published—without risking a deadlock.

If you do have to create a workflow process that can result in a deadlock, be sure to configure and assign a deadlock action that notifies the participants of the deadlock for each of the steps that can cause the deadlock. The default deadlock action is an email message that sends to the appropriate participants when a step causes a deadlock.

Understanding Workflow Groups

Workflow groups you treat several assets as one unit of work. Assets in a workflow group must be approved at the same time.

If you create a workflow process to be used with workflow groups and any of the steps can result in a deadlock, be sure to configure and assign a group deadlock action that notifies participants when there is a group deadlock and assign it to the process.

Workflow groups enable content providers to send a defined set of assets though the workflow together. While it is the content providers who create workflow groups and select the assets that are assigned to the group, you, the administrator, must know what kind of assets will be included in workflow groups so you can configure the workflow processes appropriately. See Creating Workflow Groups.

Delegating and Clearing Assignments

People go on vacation, get reassigned to new work groups, and move on to different jobs. What happens to the assets that they are working on? They can delegate their assignments to other participants who have the appropriate roles.

Each workflow process can have a workflow administrator. The administrator of a workflow process can delegate assignments on behalf of the other participants. You can specify one or more delegate actions, such as email notification, for each workflow process.

If an asset no longer must be assigned or if it is easiest to clear the assignment and then start over, you can use Clear Assignments in the Admin tab.

Placing an Asset in Workflow

An asset begins its participation in a workflow process in either of the following ways:

  • A user selects a workflow process from the Workflow Commands field on the Status form for the asset.

    Selecting the workflow process calls the start step for the process, which places the asset into the first state.

  • A user creates an asset and the start menu New item for assets of that type is configured such that there is a default workflow process.

    In this case, saving the asset calls the start step for the process, which automatically places the asset into the first state.

Because steps are enabled for specific roles, only the users who have a role that is assigned to the start step of a process can select that process. If you are using start menu items to place assets in workflow, you must be sure that the roles assigned to the start menu item are the same roles that are assigned to the start step of the default workflow.

Restricting Access to Assets While They Are in Workflow

Although workflow routes an asset through a business process, sending it to the appropriate users at the appropriate times, just because the asset is assigned to a specific user does not stop other users from modifying or even deleting that asset.

To restrict who has access to an asset while it is in workflow, use the workflow feature called function privileges. These are restrictions set on functions such as edit, copy, approve, delete, show versions, and so on in the context of workflow states and workflow roles.

There are three parts to a function privilege:

  • The function being restricted.

  • The roles allowed or not allowed to perform the function.

  • The state during which users with those roles are allowed or not allowed to perform the function.

When a function privilege is in effect, it means that a user can perform that function only when the following conditions are true:

  • The user has an appropriate role.

  • The asset is in the correct state.

  • The asset is assigned to the user.

Even if the user has the correct role and the asset is in the correct state, the user cannot perform that function on that asset unless the asset is assigned to that user.

Function privileges restrict access to a function from the user interface only. You can program step actions that call a function when a step is taken regardless of what the function privilege is set to at that moment.

The ApproveForPublish step action is an example. Even if you specify function privileges that restrict users from using the Approve option in the user interface, those same users can approve an asset with a workflow step if the workflow step calls the Approve For Publish action and the user has the correct role to take the step.

In other words, you can use function privileges to prevent users from selecting and changing assets by mistake and use actions to call those functions in a highly controlled way.

If you create even one function privilege that allows or restricts access to a function for a given role, you must create function privileges that cover all the other roles for that function.

For example, suppose that the only function to restrict is the Delete function—you want to allow only the editors to delete article assets, and only then if the article is in the Review state. If you create a function privilege that allows editors to delete article assets that are in the Review state but you do not create any other function privileges, nobody else can delete article assets that are in the Review state until you explicitly grant other roles access to the Delete function in the Review state.

If you create a function privilege that denies editors access to the Delete function for assets in the Review state, no user can delete article assets that are in the Review state until you explicitly grant other roles access to the Delete function in the Review state.

Working with Deadlines

There are two kinds of workflow deadlines:

  • Assignment deadlines – which specify how long an asset should remain in an individual state. When you set a value for the Estimated Time field of a state, that creates a deadline for the assets that are assigned to workflow participants when the assets are in that state.

  • Process deadlines – which specify how long it should take for an asset to go through the entire process.

Note that these different types of deadlines do not interact with each other—they are calculated separately and are mutually exclusive. Most likely you will use either one kind or the other, but not both for the same workflow process.

When you create a workflow state, you can set an Estimated Time for it and determine whether reminder emails should be sent when assignments miss the deadline that is calculated from the Estimated Time.

When you create a workflow process that uses the state, you specify whether the Estimated Time for the state can be changed (overridden) when a user takes the step that moves the asset into that state.

If the deadline can be changed, any participant who takes the step can override the deadline unless you configure function privileges that restrict their ability to do so. Note that any participant who has a role that was designated as an administrator role for the workflow process can always override an assignment deadline if the deadline can be changed.

When you create a workflow process, you determine whether a process deadline can be set. A process deadline is set when an asset is first placed in workflow, in the Select Workflow form. Unlike an assignment deadline, however, you cannot configure the process to send reminder emails when a process deadline is approaching.

If a process deadline can be set, any participant who places the asset in the workflow can set a process deadline for that asset—unless you configure function privileges that restrict their ability to do so. Additionally, any participant who has a role that was designated as an administrator role for the workflow process can always set a process deadline, if a deadline can be set.

Scheduling a Deadline Calculation

There are two kinds of actions:

  • Actions that are called by a step. These actions are events that completes when a step is taken.

  • Actions that are triggered by a deadline. These actions are queued and are triggered only after calculates the deadlines for the assets and determines which timed actions (if any) should be called.

You specify how often the deadlines are calculated by configuring the Timed Action Event. This is an event that calls a background calculation process of all deadlines. It is similar to the publishing event that calls the background approval calculation process.

Just as the publishing process calculates approvals to determine which assets should be published, the deadline calculation process that is called by the Timed Action Event calculates the deadlines for all assets that are participating in workflow processes—to determine whether any reminder messages should be sent for assignment deadlines and to determine the times that should be shown for assets in the Due and Process Deadline columns of assignment lists.

You can configure the Timed Action Event on your management system to run as often as you find it necessary.

Ending a Workflow Process

A workflow process ends when there are no more states for the asset to progress through. This occurs when the final participant takes the end step for the workflow process.

An end step is the opposite of a start step—it has a From State but no To State. When a user takes the end step, it is moved to a stateless state, which means the asset is no longer in workflow and any function privileges set for that workflow process no longer apply.

Planning Your Workflow Processes

When you create a workflow process, you create steps that link together the states for that process. You or someone else must create the workflow components—roles, email messages, the various kinds of actions, step conditions, and states—before you can create a workflow process.

This section provides more details about the configuration of each of the workflow components so that you can plan and implement your workflow processes. To plan a workflow process, do the following:

Starting with a Sketch

Where do you begin? With sketches of the business processes that you must implement as workflow processes:

  • Use boxes to represent the states.

  • Use arrows to represent the steps that connect the states.

As you read through the descriptions in this section, write on your sketches the details about which roles, actions, conditions, deadlines, and so on are appropriate for each state or step in the process.

Then, see your sketches as you use the administrator's interface to create your workflow processes, described in Configuring Your Workflow Processes.

Determining Roles and Participants

When you start planning your workflow processes, begin with the roles. What kind of functional groups participate in workflow? Then, determine how the individual users from those roles will become the participants in a workflow process for a specific asset.

To determine the roles that you should create for your processes, ask yourself the following questions:

  • What are the job titles or roles of the content providers who are using your WebCenter Sites management system?

  • What do the people in each role do? (You can map the tasks that they complete to your states.)

  • How are the roles organized? For example, is there one group of reviewers who review everything but several groups of content providers who are organized by subject (for example, sports writers, financial writers, marketing writers, and so on).

  • Do certain groups of people work with specific asset types but not with others? If so, which roles should have access to each asset type that you plan to create a workflow process for?

  • Would you ever have to notify someone who is not participating in a workflow about the status of an asset that is in workflow? If so, that person will require a role so a step or timed action can send an email message to that person.

On your sketches of your workflow processes, write the names of the roles that will have the asset assigned to them in each state.

For information about creating roles, see Creating a Role From the Admin Interface.

When you configure a workflow process, there are several ways to determine which specific users participate in the workflow for each individual asset that goes through the workflow:

  • When the workflow is assigned.

    You can configure the process so that the person who first assigns the workflow to the asset must select all the users who will participate. For each state, they select users from a list. The list includes all the users who have the correct role for that state.

  • When a participant finishes the assignment.

    You can configure the process so that each participant determines who the next participant is when he or she finishes the assignment. That participant selects a user name from a list that includes all the users who have the correct role for the next state.

You specify how participants are selected when you configure the steps.

Assets can be shared between sites. If a shared asset is entered into a workflow process, should users from all the sites that have access to the asset be considered as candidates for participating in the workflow? If the answer is yes, enable the cross-site assignments feature.

When you use the cross-site assignments feature, users see all of their assignments from all the sites that they have access to in their assignment list no matter which site they are currently logged into. Having one consolidated assignment list is very convenient for your users.

Keep in mind, however, that if your users have different roles in different sites and you are using function privileges in your workflow processes, they might not be able to work on an asset that they can see in their assignment lists. For example, say that some of your users have the author role in one site and the editor role in another. If you are using function privileges to restrict editing to editors in a certain state, they can see an asset that they aren't allowed to edit in their assignment list when they are logged in to the site where they function as authors.

To enable this feature, you set the value of the xcelerate.crosssiteassign property to true. This property is in the wcs_properties.json file, categorized under UI. See Properties in the UI Category in Property Files Reference for Oracle WebCenter Sites.

Determining the Email Objects, Actions, and Conditions

An action is an event that is triggered in one of three ways:

  • A step calls it (step action).

  • A deadline triggers it (timed action).

  • A workflow situation triggers it (deadlock, group deadlock, and delegate actions).

A condition is an event that is assessed when a step is attempted. If the condition is not met, the step cannot be completed.

When you create an action or a condition, you identify an element. Elements are named pieces of code that are stored in the ElementCatalog table. It is the element that calls the function represented by the action. If the element is coded to expect variables or arguments, you identify values for them when you create the action and those variables are then passed to the element when the action is triggered.

As an administrator, you are not responsible for coding elements. If your workflow requirements cannot be met by the default workflow elements that are provided, your developers can code the functionality that you require. See Customizing Workflow in Developing with Oracle WebCenter Sites.

WebCenter Sites provides the following default workflow elements:

Table 19-1 Workflow Element Names and Expected Variables

Element Name Variables It Expects

OpenMarket/Xcelerate/Actions/Workflow/ StepActions/ApproveForPublish

target

The name of the publishing destination that the asset is to be approved for.

OpenMarket/Xcelerate/Actions/Workflow/ StepActions/SendEmailToAssignees

emailname

The name of the email object to send.

OpenMarket/Xcelerate/Actions/Workflow/ StepConditions/ExampleStepCondition

 

OpenMarket/Xcelerate/Actions/Workflow/ AssignmentActions/SendEmail

emailname

The name of the email object to send.

OpenMarket/Xcelerate/Actions/Workflow /DeadlockActions/SendEmailToAssignees

emailname

The name of the email object to send.

OpenMarket/Xcelerate/Actions/Workflow/ GroupActions/SendEmailToAssignees

emailname

The name of the email object to send.

These elements are described in detail in Workflow Actions in Developing with Oracle WebCenter Sites.

With the exception of ApproveForPublish and ExampleStepCondition, these elements take a variable called emailname and send the email message that is identified by that variable.

Create workflow email objects to determine the value of the emailname variable. The names of the email objects you create in the Admin tab are the names that you specify as the arguments with the emailname variable for actions that send email messages.

This section covers the following topics:

Understanding Email Objects

Email objects are building blocks separate from the actions so that you can use them with multiple actions. For example, the default deadlock action and the default group deadlock action use the same email message (named Deadlock Message).

You create email objects by giving them a name, a description, a subject line, and text for the body. When the message is sent, the text provided for the subject is placed in the subject line and the text provided for the body is placed in the body of the message.

There are several workflow email variables that you can use in the subject line and body text which makes it easier for you to write email messages that are personalized for each recipient. The following table lists the default workflow variables that you can use with any email message:

Table 19-2 Default Workflow Variables

Variable Name Description

Variables.assetname

The name of the asset.

Use this variable in every email message so the recipient knows which asset is being referred to.

Variables.assigner

The user name of the participant who assigned the asset to the person receiving the email.

Use this variable in email messages for step actions that notify participants that a new asset has been assigned to them.

Variables.time

The time specified in the Estimated Time field for a state.

Use this variable for timed actions.

Variables.instruction

The text that the previous participant entered in the Action to Take field of the Finish My Assignment form when he or she finished the assignment.

Use this variable in email messages for step actions that notify participants that a new asset has been assigned to them.

For examples of custom email variables, see the email object named Deadlock Message and the corresponding deadlock action element named OpenMarket/Xcelerate/Actions/Workflow/DeadlockActions/ SendEmailToAssignees.

The following are the default workflow email objects:

  • Assignment Due Reminder – specifies the asset and the time that it is due.

  • Assignment Message – specifies the asset, the person who assigned it, and in the message from the Action To Take box on the Finish My Assignment form.

  • Deadlock Message – describes how the deadlock occurred by listing the users and the steps that they took.

  • Rejection Message –is similar to the Assignment Message, but states that the asset was rejected by the previous participant (the assigner).

To determine the email objects that you must create, you must also determine the actions that will send the email messages held in the objects. By using the email variables in the subject and body, it is likely that you can use the same email object with multiple timed actions or step actions.

Typically, you compose email messages that specify the following kinds of things:

  • An asset has been assigned to a participant. (For step actions.)

  • An asset has been delegated to a new participant. (For delegate actions.)

  • A deadline is approaching for an asset. (For timed actions.)

  • A deadline for an asset has been missed. (Also for timed actions.)

  • An asset is in a deadlock. (For a deadlock action.)

  • A group of assets are in a deadlock. (For a group deadlock action.)

In the Admin tab, double-click Email. Examine the default email objects to determine if you can use them. You can modify the default messages or create your own email messages. In one corner of your sketches of the workflow processes, list the email messages that you must have for that workflow.

Understanding Timed Actions

Timed actions are actions that are based on the deadline of a state. If you specify a deadline for a state, you can specify a timed action to remind the participants about the deadline.

You create a timed action by giving it a name and a description, specifying an element, and then providing argument values for the element, if necessary.

To create a timed action that sends email notices about a deadline, specify the OpenMarket/Xcelerate/Actions/Workflow/AssignmentActions/SendEmail element and use the Argument field to specify which email message to send.

When you create a state, you specify which timed actions to use and when to trigger them, relative to the deadline specified for the state. You can specify multiple timed actions for each state.

When the Timed Action Event runs and calculates the deadlines for all the assets currently participating in workflow, the appropriate timed actions are triggered.

There is one default timed action: Send Email. It uses the OpenMarket/Xcelerate/Actions/Workflow/AssignmentActions/SendEmail element to send the Assignment Due Reminder email message.

When planning your timed actions, you must also consider the following workflow components:

  • The states that you will create, because these actions are triggered in terms of the deadlines that you set for your states.

  • The email objects that you must create, because it is likely that your timed actions will send email messages.

Because the time that a timed action is triggered is determined outside of the action itself (you do this in the form for the state), you can probably create a small number of generic timed actions—whose only difference is the email message they send—and use them repeatedly with your states.

In the General Admin tree, expand the Workflow node, then expand Actions, and then Timed Actions. Examine the Send Email action to determine whether you can use it. You can modify the default timed action or create your own.

On each of your sketches of your workflow processes, list the timed actions that you must have for that process near the list of the email messages.

Understanding Delegate Actions

When you assign a delegate action to a workflow process, the action is triggered whenever a participant (or the workflow administrator) delegates an assignment to another participant.

You create a delegate action by giving it a name and a description, specifying an element, and then providing argument values for the element, if necessary.

You can specify one delegate action per workflow process. There are no default delegate actions provided.

It is likely that your delegate action will send an email message to the participant to whom an assignment is delegated. If this is the case, you can create a delegate action that uses any of the default workflow elements that send email and create a new email object for that element to send.

On each of your sketches of your workflow processes, write the name of the delegate action that you will use for that process. (You can assign one for each process.)

Understanding Step Actions

When you assign a step action to a step, the action is triggered when a participant takes the step.

You create a step action by giving it a name and a description, specifying an element, and then providing argument values for the element, if necessary.

There are two general categories of step actions: those that complete functions and those that send email messages to the participants who are being assigned the asset by the step.

Step actions are completed regardless of function privileges. That is, if you create a step action that performs a function, the action does not check the function privileges of the participant taking the step. You can restrict access to a function from the user interface and require participants to use a step in a workflow to complete a specific function (approve for publish, for example).

You can specify one or more step actions for each step.

The default step actions are these:

  • Approve for Publish, which uses the OpenMarket/Xcelerate/Actions/Workflow/StepActions/ApproveForPublish element to approve the asset. Then, the next time a publishing process runs, the asset is published (if all of its dependencies are also approved).

    To use this action for your workflow processes, you must specify the publishing destination(s) that the asset is to be approved for by using the targets argument.

  • Send Assignment Email, which uses the OpenMarket/Xcelerate/Actions/Workflow/StepActions/SendEmailToAssignees element to send the Assignment Message email object to all the participants assigned the asset (that is, who are specified in the Assignment Method for the step).

  • Send Rejection Email, which uses the OpenMarket/Xcelerate/Actions/Workflow/StepActions/SendEmailToAssignees element to send the Rejection Message email message to the new assignee (the participants specified in the Assignment Method for the step).

To determine what kind of step actions you must create, you must consider the following workflow components:

  • The steps that you will create for the process. Do people have to be notified that a step has assigned an asset to them? If so, you require a step action that sends an email message.

  • The states that the steps move the assets into. Does the state represent the asset after a function has been completed? If so, you require a step action that implements that function.

In the Workflow tab, select Actions, then Step Actions. Examine these actions to determine whether you can use them. You can both modify the default step actions and create your own.

On each of your sketches of your workflow processes, write the name of the step actions next to the appropriate steps. You can assign one or more step actions for each step.

Understanding Step Conditions

When you assign a step condition to a step, the condition is assessed when the step is taken. The condition determines whether the step can be completed or not.

You create a step condition by giving it a name and a description, specifying an element, and then providing argument values for the element, if necessary. To use conditions in your workflow processes, talk to your developers about the conditions you must have them to implement through elements.

You can specify one or more conditions for each step.

There is one default step condition: Example Step Condition. It is a "hello world"-style example that illustrates how to code an element to check for a condition. You and your developers should examine it to learn how it works and then your developers should create their own condition elements.

When thinking about step conditions, you must consider the steps and the state. If you determine that conditions are necessary for your workflow processes, ask your developers to create them.

On each of your sketches of your workflow processes, write the name of any step conditions that you require next to the appropriate steps.

Understanding Deadlock Actions

When you assign a deadlock action to a step that can result in a deadlock, the action is triggered whenever an asset becomes deadlocked during the step.

You create a deadlock action by giving it a name and a description, specifying an element, and then providing argument values for the element, if necessary.

You can assign one or more deadlock actions per step.

There is one default deadlock action: Send Deadlock Email. It uses the OpenMarket/Xcelerate/Actions/Workflow/DeadlockActions/SendEmailToAssignees element to send the Deadlock Message email message.

When thinking about possible deadlock actions, you have to consider the steps that you will create for your workflow processes. If you plan to design your steps so that deadlocks cannot occur, you do not have to create any deadlock actions.

In the Workflow tab, expand Actions, then Deadlock Actions. Examine this action to determine whether you can use it. You can modify the default deadlock action or create your own.

In your sketches of your workflow processes, write the name of the appropriate deadlock action next to any step that can result in a deadlock.

Understanding Group Deadlock Actions

A group deadlock action is triggered when workflow group becomes deadlocked. Whoever creates the workflow group selects the group deadlock action. That person can select one or more actions for each group.

The group deadlock actions are called in addition to any other actions that are associated with the states or the steps in the workflow process. There is one default group deadlock action: Send Deadlock Email. It is identical to the default deadlock action.

The same considerations apply for group deadlock actions as for deadlock actions. However, because it is a content provider who selects the group deadlock action for a workflow group, be sure that you give a group deadlock action a meaningful, unambiguous name.

Determining States

When you create a state, you specify the following kinds of information:

  • Name and description. The name of a state should be meaningful and should represent the kind of work that is being done while the asset is in that state.

  • Amount of time an asset should remain in this state (the Estimated Time). The deadline is calculated in terms of the number of hours or days since the asset entered the state.

    Note that you set the estimated time (the deadline) in terms of hours or days rather than as a specific date because a state deadline is calculated for each asset as it passes through the state.

  • The timed actions that should occur and when they should occur, in terms of days or hours before or after the deadline.

There are no default states, although there are example states provided with all of the sample sites. On a system where the sample sites are installed, select Workflow, then select States, and then select a state to examine to learn about how the sample site states are configured.

To determine the states that you have to create, ask yourself the following kinds of questions:

  • Which roles participate in each state? On your sketches, write the names of the roles next to the states.

  • Do any of these states apply to multiple asset types? If so, it's possible that you can reuse the same state in multiple workflow processes.

  • How long should it take to complete each state?

  • Does this amount of time differ by asset type or by site? If yes, you cannot reuse the same state in multiple workflow processes or share the workflow process with another site.

  • If there is a deadline, should notify the participant when the deadline is approaching? If yes, when? The day before? Several hours before? And which timed action (which determines which email message) should be used?

  • Should there be a notice when a deadline is missed? If yes, when? And which timed action should be used?

On the sketches of your workflow processes, list all of this information next to each state.

Depending on your goals, consider creating a workflow process that does not really end. For example, the Hello Asset World sample site workflow process ends after a HelloArticle asset has been approved. However, in a case like this, someone could open and save the asset by mistake, which would mean that it is no longer approved and no longer published.

To keep assets from being edited after they have been approved and before they have been published, you could create a final state that holds assets after they have been approved with a function privilege on the state that restricts anyone from editing the asset.

Be sure that if you do create a state like this that you create a step that can move the asset back into an editing state in the workflow so someone can edit it on purpose.

Determining Steps

You create steps within a process. You use the steps to link together the states. This is how the process is actually created.

You specify the following kinds of information for each step in your process:

  • The name of the step. The name should be meaningful and should describe the path being taken. For example, Send for Review, Send for Approval, and so on.

  • The From State, which is the state that the step is moving the asset from. If the step has no From State, it is the start step that begins the workflow process. A From State is required for each step other than the start step.

  • The To State, which is the state that the step is moving the asset to. If the step has no To State, it is the end step the ends the workflow process.

  • Which roles are authorized for the step.

    If this is the very first step, the roles you specify determine which users can select this workflow for an asset. If you are using a Start Menu item to assign the workflow process to an asset, be sure that the roles assigned to this first (start) step match the roles assigned to the Start Menu item.

    For subsequent steps after the first (start) step, the roles that you select must either match or be a subset of the roles that were selected to be notified by the previous step. Otherwise, the asset cannot leave the state because no one who is assigned the asset is allowed to move it to the next state.

  • Who gets the asset next? (That is, when this step is completed). You specify the assignee for the To State by selecting either of the following assignment methods:

    • Retain From State assignees.

      This option assigns the asset to its current assignees—that is, to the user who completes the step.

      This option is useful when you are creating a step that returns to the same state (which creates an iterative state) or when it is the start step and you want the asset to be assigned to the person who selects the workflow process (whether through a start menu item or by selecting it on the Status form).

    • No assignments; control actions with function privs.

      This option keeps the asset in the workflow process, which means that function privileges are enforced, but the asset is not actually assigned to anyone.

      Note:

      When an asset is assigned to the current assignees (Retain From State assignees option) or assigned to no one (No assignments option), the workflow system records workflow history for that step.

    • Assign from a list of participants.

      With this option, you select roles. When a user assigns the workflow process to an asset, a list of users with the roles that you selected is shown. The user selects one or more users from the list, and those users are assigned the asset when it is in the state that this step moves the asset to.

    • Choose assignees when the step is taken.

      You also select roles with this option. This option means that the person who takes this step (by completing the assignment) during the workflow process selects the user who is assigned the asset next from a list of users with the roles selected for the step.

  • Whether the estimated time for the state that this step moves the asset to can be changed or not. (Called an Assignment Deadline.)

  • Any step actions that should occur.

  • Any step conditions that should be assessed.

  • If the step can be taken by multiple users (assignees), whether all the assignees must take this step before the asset can move to the next state. (The All assignees must vote field.)

  • If the step can result in a deadlock, what the deadlock action should be.

  • If the process is used for a workflow group, whether all the assets in the group must complete this step before any of the assets can move to the next state. (The Step is group synchronized field.)

There are example steps in all of the sample site workflow processes. On a system where the sample sites are installed, select Workflow, then select Processes and examine a process to learn about how the sample workflow steps are configured.

When determining what your steps should be, consider the following questions:

  • Every process requires a start step. Before you create a start step, you must first determine how the asset is created and then placed into workflow.

    Does the first participant create the asset, place it into workflow, and then keep working on the asset? If so, configure the step so that it is assigned to the person taking the start step (choose the Retain "From State" assignees option) and remember to create a start menu item that assigns the workflow to the asset by default.

    Or does a supervisor create the asset and then assign to it a participant? If so, configure the start step so that the person taking the start step has to select the assignees.

  • What is the order of the states?

  • How many paths do you require between each state? This answer determines how many steps you must have.

  • Do you have to create an iterative state? If so, configure the step that takes the asset back to that state so that it is assigned to the person taking the step (choose the Retain "From State" assignees option).

  • For steps that move an asset from a state in which multiple people are working on that asset, must all the participants complete their assignment before the step can be taken? If so, configure the step to be an all-voting step.

  • Does the asset have multiple possible paths from a state? (That is, there must be multiple steps with the same From State.) If yes, do any of the steps from the state require that all participants vote the same way before the asset can progress? If yes, try to design the process so only one step that leads from that state require that all the participants vote the same way. If you have two all-voting steps from the same state, deadlocks can occur.

  • For each step, should notify the affected participants when the step is completed and the asset progresses to the next state? If yes, which step action (which determines the email message) should the step use?

  • Do groups of related assets ever have to be worked on at the same time? If so, can you configure your steps to work appropriately for both a single asset and a group of assets? If not, create separate workflow processes for the workflow groups.

  • For a workflow group, are there any states that all the assets in the group must enter at the same time? (For example, all the assets should be approved at the same time.) If so, configure that step to be a synchronize step. Note that it's best to have only one synchronize step per workflow process.

  • What should happen to the asset if you decide not to publish it, after all? Should you have a cancel step? How many cancel steps are necessary?

On your sketches of your workflow processes, right next to the box that represents a step, list the step actions, the roles who can take the step, the roles who should be notified when the step is taken, whether the step is an all-voting step, and whether the step is a synchronize step.

Determining Function Privileges

Administrators grant or deny roles the privilege to use functions (such as create and edit) on a given site. When the privilege is granted, the functions are shown to site users with those roles. Users can call the functions when an asset is in the state specified by the privilege. (By default, function privileges are granted to all roles on a given site.)

You can set function privileges for each function in a workflow process, as necessary. Instructions for setting function privileges can be found in (Optional) Configure Function Privileges for the Workflow Process.

The following table lists the functions that you can allow or disallow users to perform during a workflow process.

Table 19-3 Functions and User Action Allowances

Function If the Function Privilege is Granted...

Abstain from Voting

Users have the option to not vote in a workflow step.

Shown as an option in the Workflow Commands drop-down menu on the asset's Status form.

Approve for Publish

Users can select an asset as approved for publishing.

Shown as an option in the more... drop-down menu on the asset's Inspect and Status form.

Authorize

Users can configure permissions to an asset.

Build

Users can build a collection asset.

Shown as an option in the more... drop-down menu on an asset's Inspect and Status forms.

Checkout

Users can check out an asset, if revision tracking is enabled for the asset type.

Shown as the Check Out button at the top of an asset's Edit and Status forms.

Copy

Users can copy an asset.

Shown as an option in the more... drop-down menu on an asset's Inspect and Status forms.

Delegate Assignment

Users can delegate an asset (assigned to themselves) to another user (one who has the appropriate role for the asset while it is in that state).

Shown as an option in the Workflow Commands drop-down list on the asset's Status form.

Delete

Users can delete an asset.

Shown as an icon in the action bar on an asset's Inspect and Status forms. Also shown as an icon next to the asset in lists.

Edit

Users can open an asset in its Edit form.

Shown as an icon in the action bar on an asset's Inspect and Status forms. Also shown as an icon next to the asset in lists.

Inspect

Users can open an asset in its Inspect form.

Note: Users without permission to inspect an asset cannot view any data specific to the asset type. Instead, they see a limited version of the Inspect form, which shows only standard, unrestricted fields (such as name, description, and ID).

Make Root of Translation

Users can set an asset as the master asset of translations. (Used by multilingual assets.)

Shown as the Make Master link in the Translations field of a multi-lingual asset's Inspect form.

Place Page

Users can place a page on the Site Plan tab.

Shown as an option in the context menu on the Site Plan tab when the user right-clicks Placed Pages.

Preview

Users can view an asset in the context of its page.

Shown as the Preview icon in the asset's toolbar.

Remove from Group

Users can remove the asset from a workflow group.

Shown as an option in the Workflow Commands drop-down list on the asset's Status form.

Remove from Workflow

Users can remove the asset from a workflow process.

Shown as an option in the Workflow Commands drop-down list on the asset's Status form.

Rollback

Users can return an asset to one of its previous versions (all of which are stored in the revision tracking system).

Note: This function is shown as the Rollback button at the top of an asset's Edit and Status forms when revision tracking is enabled and at least two versions of the asset exist.

Set Export Destination Path/Filename

Users can fill in the Path and Filename fields on an asset's New or Edit forms.

Set Participants

Users can set participants for a workflow process.

Shown as an option in the Workflow Commands drop-down list on the asset's Status form.

Additionally, this function prompts the user to select participants when the workflow process is configured. In this manner, the user finishing an assignment must select the next participant (person being assigned the asset).

Set Process Deadline

Users can set a deadline indicating the date and time by which the workflow process must be completed.

Note: This function is shown only if the workflow is configured to allow its users to set a process deadline. This function then is an option in the Select Workflow form for assets, and when a workflow group is created or edited.

Set Assignment Deadline

Users can set a deadline indicating the date and time by which the next state must be completed. A deadline set with this option overrides any deadlines set for the state in the workflow process.

Note: This function is shown only if the workflow is configured to allow its users to set an assignment deadline. This function then is an option in the asset's Select Workflow form and in the Finish My Assignment form.

Share Assets

Users can share the asset with another CM site.

Shown as the Share Asset option in the more... drop-down menu on an asset's Edit, Inspect, and Status forms when the asset type is enabled for multiple CM sites.

Show Participants

Users can view a list of the participants in the workflow process that is currently assigned to the asset.

Shown as an option in the Workflow Commands drop-down list on the asset's Status form.

Show Status

Users can view the Status form for an asset.

Shown as an option in the more... drop-down menu on an asset's Inspect and Status forms.

Show Version

Users can view information about each version of the asset that the revision tracking system is storing.

Shown as the Show Versions button at the top of an asset's Edit and Status forms when revision tracking is enabled for this asset type.

Set Nested Workflow

Users can create a workflow within an existing workflow.

Note: The administrator's interface does not support nested workflow, but functionality can be obtained with the use of tags.

Translate

Users can create a translation of the master asset. (Used by multilingual assets.)

Shown as an option in a multi-lingual asset's more... drop-down menu, on the Edit, Inspect, and Status forms.

For each workflow process, determine which functions you want to restrict access to, during which states you want to restrict those functions, and which roles should or should not have access to those functions when assets that are assigned to them are in those states. List any restrictions to enforce next to the appropriate states on your sketches of your workflow processes.

In order for your function privileges to enforce the restrictions that you intend, the roles of the users specified for the state in the function privilege must match the roles of the users associated with those states in the workflow process. If the roles don't match, the result can be a condition in which no one can move the asset out of a state.

Also, remember that if you create even one function privilege that allows or restricts access to a function for a given role, you must create function privileges that cover all the other roles for that function.

Because function privileges are associated with workflow processes, you can restrict individual users' access to specific functions only when an asset is participating in a workflow process.

What can you do if you do not want to design and implement workflow processes but you still want to control access to specific functions? Create a simplified workflow process with one state and use the No assignments; control actions with function privs assignment method.

When a step moves an asset into a state using the No assignments assignment method, the asset does not appear on anyone's assignment list, it just stays in the state which means that any function privileges assigned to that state are enforced.

Implementing Simplified Access Control

To implement access control:

  1. Create a state. It requires a name and a description. It does not require a deadline or any timed actions.
  2. Create a new workflow process. Select all the roles you want to enforce restrictions for and all the asset types you want to use this workflow process for.
  3. Create one step— the start step that puts assets of those types into the state. For the step, select the No assignments option. Enable the step for the roles to be able to create assets of this type and assign this workflow to.
  4. Configure the function privileges to enforce for assets in the state that you created.
  5. Create start menu items for the asset types that automatically assign this workflow process. Be sure that the roles who can use the start menu item match the roles who are assigned to the start step in the workflow process.

Now when users select New, then select asset type, the new asset is automatically placed into your single-state workflow. Because the workflow has only the start step which places all assets of that type into the single state, those assets do not leave the state and the function privileges are always enforced.

Determining Additional Workflow Process Details

If you have been sketching your workflow processes, filling in all the details about actions, conditions, email messages, states, steps, and function privileges, by now you have planned nearly the entire design of your workflow processes.

Although the main task when creating a process is to create the steps that link the states (which is how your business process is represented), you must also specify the following kinds of information for each workflow process:

  • Its name and description. The name should be descriptive so that users select the correct workflow process for the correct asset types.

  • Which sites can use the process.

  • Which asset types can use the process.

  • Which roles can participate. This is a superset of all the roles that are designated in the steps.

  • Which role will serve as the administrator of the workflow. A workflow administrator can delegate assignments on behalf of other participants.

  • Whether a process deadline can be set for assets that participate in this workflow process.

  • What the delegate action is.

  • What the steps are. For each step, you specify the information described in Determining Steps.

  • Whether any of the WebCenter Sites content application functions should be restricted to users in certain roles while they are working on assets in specific states. For function privileges, you specify the information described in Determining Function Privileges.

Configuring Your Workflow Processes

This section presents the procedures for creating all the components for a workflow process and then stitching those components together into your workflow processes.

Remember that to create email objects, actions, and conditions or to schedule the timed action event, you must have access to the Admin tab, which means that you require the GeneralAdmin role and the xceladmin ACL. To create workflow states and workflow processes, you must have access to the Workflow tab, which means that you require the WorkflowAdmin role.

For more information about access rights in the WebCenter Sites interfaces, see Working with ACLs and Roles and Configuring Users, Profiles, and Attributes.

Before you create a workflow process, you must create the individual workflow components that you require for that process. Here are the general steps that you must take presented in the order you perform them:

Table 19-4 System Locale Properties

Workflow Processes Workflow Components

Plan your workflow process by drawing it. Then see your sketch and notes throughout this topic.

Planning Your Workflow Processes

Create the roles that you require for your workflow processes. Be sure that any users who will participate in workflow have user profiles created for them. Otherwise, they will not receive email messages from the workflow process.

Note:

Create the roles that you require for your workflow processes. Be sure that any users who will participate in workflow have user profiles created for them. Otherwise, they will not receive email messages from the workflow process.

Determining Roles and Participants

Create the email objects that you require for your actions and enable the xcelerate.emailnotification property in the wcs_properties.json file.

Setting Up Email Objects

Create the step actions, timed actions, deadlock actions, group deadlock actions, and delegate actions necessary.

Setting Up the Actions and Conditions

Create your states.

Setting Up the States

Create your process. While creating your workflow process, you create the steps for that process. The steps link together the states so they occur in the proper order. Additionally, while creating your process, you configure any function privileges necessary. Setting Up the Workflow Processes
If your states have deadlines, be sure to configure the Timed Action Event so that the deadlines of assets are calculated regularly and the appropriate timed actions (if any) are called in a timely way. Setting Up the Timed Action Event
Test your workflow processes. Testing Your Workflow Process
Set up your start menu shortcuts so that workflow processes are assigned automatically to assets when they are created. Managing Start Menu Items

Setting Up Email Objects

You create email objects so that your step and timed actions can send them to the appropriate participants at the appropriate times. Examine the sketches of your workflow processes, determine the email messages you must have, and then use the procedures in this section to create and edit them.

Your user account must give you access to the Admin node, under the General Admin tree, in order for you to create email objects.

To ensure that your workflow process can successfully send email messages, the following conditions must be true:

  • The following properties must be configured to provide information about your email server:

    • cs.emailaccount

    • cs.emailauthenticator

    • cs.emailcharset

    • cs.emailcontenttype

    • cs.emailhost

    • cs.emailpassword

    • cs.emailreturnto

  • The xcelerate.emailnotification property must be set to true.

    See the Properties in the Core Category in Property Files Reference for Oracle WebCenter Sites.

  • The workflow participants must have email addresses specified in their user profiles.

The following topics provide instructions for working with email objects:

Creating Email Objects

  1. In the General Admin tree, expand the Workflow node, expand the Emails node, and then double-click Add New.

    The Add New Workflow Email form opens.

    Figure 19-4 Add New Workflow Email Form

    Description of Figure 19-4 follows
    Description of "Figure 19-4 Add New Workflow Email Form"
  2. In the Name field, enter a unique name of up to 36 characters. This is the name that you provide to the emailname variable when you use this email object with an action.

    Note:

    The double quote ("), less-than sign (<), and greater-than sign (>) characters are not allowed in the Name field. Additionally, the name cannot end with a backslash (\).

  3. In the Description field, enter a short, informative description of up to 36 characters.
  4. In the Subject field, enter a short, informative subject for the email message.
  5. In the Body field, enter the text for the message.
  6. Click Save.

Editing Email Objects

  1. In the General Admin tree, expand the Workflow node, expand the Emails node, and then double-click the email object.
  2. In the action bar, click Edit.

    The Edit Workflow Email form opens.

  3. Make the changes necessary and click Save.

Deleting Email Objects

  1. In the General Admin tree, expand the Workflow node, expand the Emails node, and then double-click the email object.
  2. In the action bar, click Delete.

    A warning message opens.

  3. Click Delete Email.

Setting Up the Actions and Conditions

When you create any kind of action or a step condition, you identify an element and you supply values for the variables that the element expects. If you are creating an action that sends an email message, you identify which email object to send with the emailname variable.

Before you begin creating actions or step conditions, be sure that you have the elements and email objects that you must have. WebCenter Sites provides several default action elements and email objects. Use the administrator's interface to examine the email objects and use WebCenter Sites Explorer to examine the ElementCatalog table. Determine which elements you plan to use and then write down the entire name of those elements. If you require additional email messages, consult Setting Up Email Objects and create the email messages that you must have.

The following procedures describe how to create, edit, and delete the workflow actions—step, timed, delegate, deadlock, and group deadlock action—and step conditions:

Note:

Your user account must give you access to the Workflow tab in order for you to create actions or conditions.

Creating Actions and Conditions

  1. In the Workflow tab, expand Actions.
  2. Under Actions, expand the category describing the action you are creating, then double-click Add New.

    The available categories are: Step Actions, Step Conditions, Timed Actions, Delegate Actions, Deadlock Actions, or Group Deadlock Actions.

    The Add New form corresponding to the type of action you selected opens.

    Figure 19-5 Add New Step Action Form

    Description of Figure 19-5 follows
    Description of "Figure 19-5 Add New Step Action Form"

    This example shows the Add New Step Action form.

  3. In the Name field, enter a unique name of up to 40 characters.

    Note:

    The following characters are not allowed in the Name field: double quote ("), less-than sign (<), and greater-than sign (>). Additionally, the name cannot end with a backslash (\).

  4. In the Description field, enter a short, informative description of up to 40 characters.
  5. In the Element Name field, enter the name of the element in its entirety.

    For example, to use the default workflow element SendEmailToAssignees, enter:

    OpenMarket/Xcelerate/Actions/Workflow/StepActions/SendEmailToAssignees

  6. In the Arguments field, use the following convention to supply values for the arguments or variables that the element requires to function correctly:
    name=value
    

    For the SendEmailToAssignees element, for example, you must provide a value for the emailname variable (that is, the name of an email object). For example:

    emailname=AssignmentDueReminder
    

    If an element takes multiple variables, separate the name/value pairs with the ampersand (&) character. For example:

    name1=value1&name2=value2
    
  7. Click Add New Action.

Editing Actions and Conditions

  1. In the Workflow node, expand Actions.
  2. Under Actions, expand the category describing the action you want to edit.

    The available categories are: Step Actions, Step Conditions, Timed Actions, Delegate Actions, Deadlock Actions, or Group Deadlock Actions.

  3. Under the selected category, double-click the action you want to edit.
  4. In the action bar, click Edit.
  5. Make your changes, and then click Save.

Deleting Actions and Conditions

  1. In the Workflow tab, expand Actions.
  2. Under Actions, expand the category describing the action you want to delete.

    The available categories are: Step Actions, Step Conditions, Timed Actions, Delegate Actions, Deadlock Actions, or Group Deadlock Actions.

  3. Under the selected category, double-click the action you want to delete.
  4. In the action bar, click Delete.

    A warning message opens.

  5. Click Delete Action.

Configuring Approve for Publish Step Actions

The approval process approves an asset to a specific publishing destination. To use the default Approve for Publish step action with your workflow processes, you specify the publishing destination for the assets that are approved by the action.

If all the assets for all of your workflow processes are published to the same destination, you can simply configure the existing Approve For Publish action. However, if some types of assets are published to a different destination than the others, you need an additional action for each publishing destination.

The Approve for Publish step action uses the OpenMarket/Xcelerate/Actions/Workflow/StepActions/ApproveForPublish element which takes the targets variable. You can use this same element with as many additional approval step actions as you must have.

For the default Approve for Publish step action, provide a value for the targets variable. Possible values for the targets variable are the names of any of the publishing destinations that have been created on this system.

For example:

targets=serverX.

To specify multiple publishing destinations, separate each with a comma. For example:

targets=serverX,serverY

Note:

If the name of a publishing destination that is referenced by the targets variable is changed, you must also change the value of the targets variable in your Approve for Publish steps.

Setting Up the Timed Action Event

Before any of your timed actions can be triggered, you must configure the timed action event so that it calculates deadlines at regularly occurring intervals. Note that there can be only one timed action event per WebCenter Sites system.

  1. In the Workflow tab, double-click Timed Action Event.
  2. In the action bar, click Edit.

    The Edit Workflow Timed Action Event opens.

    Figure 19-6 Edit Workflow Timed Action Event

    Description of Figure 19-6 follows
    Description of "Figure 19-6 Edit Workflow Timed Action Event"
  3. Set the schedule for how often the state deadlines should be calculated in terms of months, days, hours and minutes, depending on the selected interval. Selected values are highlighted in blue. All values are toggled separately, so it is not necessary to use Ctrl to select multiple values.

    The method of setting a timed action event is similar to the method for setting a publication event.

  4. In the Enabled Dates and Times field, select Enabled.
  5. Click Save.

    A summary of the schedule opens.

WebCenter Sites uses the same abbreviations and codes to summarize the schedule for the timed action event that it does for your publishing events. For information about how to read the schedule, see Reading the Schedule Abbreviations.

Setting Up the States

When you create a workflow state, you specify a deadline, select a timed action, and configure when the timed action should run. Before you create your workflow states, be sure that you have created the timed actions that you must have.

The following procedures describe how to create, edit, and delete workflow states:

Note:

To work with workflow states, your user name must be assigned the WorkflowAdmin role for the site that you are working with.

Creating Workflow States

  1. In the Workflow tab, expand States and double-click Add New.

    The Add New Workflow State form opens.

  2. In the Name field, enter a unique, meaningful name of up to 40 characters.

    Note:

    The following characters are not allowed in the Name field: double-quote ("), less-than sign (<), and greater-than sign (>). Additionally, the name cannot end with a backslash (\).

  3. In the Description field, enter a short, informative description of up to 40 characters.

  4. (Optional) In the Estimated Time fields, configure the deadline for assets in this state. You can specify a deadline in terms of days, hours, or a combination of the two.

  5. (Optional) Click Add Timed Actions and complete the following steps:

    Figure 19-7 Add Timed Action to Workflow State Form

    Description of Figure 19-7 follows
    Description of "Figure 19-7 Add Timed Action to Workflow State Form"
    1. In the Action to Take list, select a timed action.

    2. In the Offset field, specify whether the action should be triggered before the deadline or after the deadline.

    3. In the Days field and/or the Hours field, specify how many hours or days before or after the deadline that the action is to be triggered.

    4. Click Add Timed Action.

    5. Repeat this entire step for each timed action to set up for this state.

  6. Click Add New State.

Editing Workflow States

  1. In the Workflow tab, expand States and double-click the state to edit.
  2. In the action bar, click Edit.

    The Edit form opens.

  3. Make the changes.
  4. (Optional) To change the timed action or the time that it is scheduled to run, click Add Timed Actions, make the appropriate changes, and click Add Timed Actions again.
  5. Click Save.

Deleting Workflow States

  1. In the Workflow tab, expand States and double-click the state you want to delete.
  2. In the action bar, click Delete.

    A warning message opens.

  3. Click Delete State.

Setting Up the Workflow Processes

When you create a workflow process, you specify global process information, and then you create steps, assigning step actions to them as required. The steps in the process create the flow of the process by linking the states in a specific order. Before you can begin creating a workflow process, you must have created your step actions, step conditions (if necessary), and states.

To work with workflow processes, your user name must be assigned the Workflow Admin role for the site you are working with.

Note:

If your content providers will use workflow groups, be sure to enable the Workflow Groups tab for them. See Creating the Workflow Groups Tab.

The following procedures provide instructions for setting up a workflow process:

Editing Workflow Processes

  1. In the Workflow tab, expand Processes and double-click the workflow process you want to edit.
  2. In the action bar, click Edit.

    The Workflow Process form opens.

  3. Make your changes as follows:
  4. When you are finished, click Save.

Editing Workflow Steps

  1. In the Workflow tab, expand Processes and double-click the workflow process you want to work with.
  2. In the action bar, click Edit.

    The Workflow Process form opens.

  3. Click Add/Edit Steps.

    The Steps for Workflow Process form opens.

  4. Click Edit next to the step you want to edit.

    The Edit Workflow Process Step form opens.

  5. Make your changes, and then click Save.

    The process is saved and the Inspect form opens.

Editing Function Privileges

To edit a function privilege, you must delete it and then re-create it.

  1. In the Workflow tab, expand Processes and double-click the workflow process you want to work with.
  2. In the action bar, click Edit.

    The Workflow Process form opens.

  3. Click Add/Edit FunctionPrivs.

    The Functions for Workflow Process form opens.

  4. Click Remove next to the function to change.

    A confirmation dialog opens.

  5. Click OK.
  6. Click New next to the function you just removed.

    The Add Function Privilege form opens.

  7. Make your function privilege selections and click Save.

    The Functions for Workflow Process form opens.

  8. Click Save.

    The workflow process is saved and the Inspect form opens.

Copying Workflow Processes

You can copy a workflow process, which can save you some steps in configuring additional processes.

  1. In the Workflow tab, expand Processes and double-click the workflow process you want to copy.
  2. In the action bar, select Copy Process from the drop-down list.

    The Copy Workflow Process form opens.

    Figure 19-8 Copy Workflow Process Form

    Description of Figure 19-8 follows
    Description of "Figure 19-8 Copy Workflow Process Form"
  3. In the Process Name field, enter a unique name for the process.

    Note:

    The following characters are not allowed in the Name field: double quote ("), less-than sign (<), and greater-than sign (>). Additionally, the name cannot end with a backslash (\).

  4. In the Description field, enter a short, informative description of the process.
  5. Click Save.
  6. Edit the process as necessary. See the following procedures for help:

Deleting Workflow Processes

  1. In the Workflow tab, expand Processes and double-click the workflow process you want to delete.
  2. In the action bar, click Delete.

    A waning message opens.

  3. Click Delete Process.

    The process has been deleted.

Deleting Workflow Steps

  1. In the Workflow tab, expand Processes and double-click the workflow process you want to work with.
  2. In the action bar, click Edit.

    The Edit Process form opens.

  3. Click Add/Edit Steps.

    The Steps for Workflow Process form opens.

  4. Click Remove next to the step you want to delete.

    A dialog box opens.

  5. Click OK.
  6. Click Save.

    The workflow process is saved, and the Inspect form opens.

Deleting Function Privileges

  1. In the Workflow tab, expand Processes and double-click the workflow process you want to edit.
  2. In the action bar, click Edit.

    The Workflow Process form opens.

  3. Click Add/Edit FunctionPrivs.

    The Functions for Workflow Process form opens.

  4. Click Remove next to the function privilege you want to delete.
  5. Click Save.

    The workflow process is saved, and the Inspect form opens.

Creating Workflow Processes

When you create a workflow process, you configure three categories of information: global process settings, steps, and function privileges.

To create a workflow process, perform the instructions in the following procedures:

Name and Set Global Settings for the Workflow Process

  1. In the Workflow tab, expand Processes and double-click Add New.

    The Workflow Process: (new) form opens.

  2. In the Name field and enter a unique name of up to 25 characters.

    Note:

    The following characters are not allowed in the Name field: double quote ("), less-than sign (<), and greater-than sign (>). Additionally, the name cannot end with a backslash (\).

  3. In the Description field, enter a short, informative description of up to 64 characters.
  4. In the Sites list, select the sites that can use this workflow process.
  5. In the Asset Type list, select the asset type(s) that this workflow process is for.
  6. In the Roles list, select the roles that will participate.
  7. In the Administration Roles list, select the roles that can act as the administrator for this workflow process when an asset is using it.
  8. In the Process Deadline section, specify whether the workflow administrator (or other user if you configure function privileges that allow it) can set a process deadline for the assets that participate in this workflow process.
  9. If you have configured one or more delegate actions, select the appropriate actions in the Delegate Actions list.
  10. In the Start Step section, click Add New Step.

    The Add New Workflow Process Step form opens.

  11. Create the start step.

Create the Start Step for the Workflow Process

Figure 19-9 Add New Workflow Process Step Form

Description of Figure 19-9 follows
Description of "Figure 19-9 Add New Workflow Process Step Form"
  1. In the Step Name field, enter a unique, meaningful name of up to 64 characters.

    Note:

    The following characters are not allowed in the Name field: double quote ("), less-than sign (<), and greater-than sign (>). Additionally, the name cannot end with a backslash (\).

  2. Configure the states as follows:

    1. In the From State list, select none (start of workflow).

    2. In the To State list, select the name of the first state in the workflow process.

  3. In the Authorized Roles list, select the roles that are allowed to take this step by assigning this workflow to an asset.

  4. In the Assignment Method section, specify which roles are assigned the asset by selecting among the following options:

    • Retain "From State" assignees, which, for a start step, means that the user who assigns the workflow to the asset is assigned the asset

    • No assignments; control access with function privs

    • Assign from list of participants

    • Choose assignees when step is taken

      If you select either Assign from list of participants or Choose assignees when step is taken, select the appropriate roles from the list that is to the right of those options. (For definitions of these options, see Determining Steps.)

    • Assign to everyone

  5. In the Assignment Deadline section, determine whether the workflow administrator (or another user holding the appropriate function privileges) can override the Estimated Time (deadline) set for the state that this step moves the asset to.

  6. (Optional) In the Step Actions list, select one or more step actions that should be called when this step is taken.

  7. (Optional) In the Step Conditions list, select a step condition, if appropriate.

  8. (Optional) Select the Voting check box to select that all assignees must vote to approve.

  9. (Optional) Select the Workflow Groups check box to have the step group synchronized.

  10. Click Save.

    The start step is added and the Steps for Workflow Process form opens.

  11. Click Save.

    The Inspect form opens. Note that this step opens as the Start Step in the form.

Create the Subsequent Workflow Steps

Use the following procedure to create the rest of the subsequent steps, including the end step:

  1. In the Inspect form of the workflow process, click Edit in the action bar.

    The Edit form opens.

  2. Click Add/Edit Steps.

    The Steps for Workflow Process form opens.

  3. Click Add New Step.

    The Add New Workflow Process Step form opens.

  4. In the Step Name field, enter a unique, meaningful name of up to 64 characters.

    Note:

    The following characters are not allowed in the Name field: double quote ("), less-than sign (<), and greater-than sign (>). Additionally, the name cannot end with a backslash (\).

  5. Configure the states as follows:

    1. In the From State list, select the name of the state that you selected as the To State for the previous step.

    2. In the To State list, select the name of the next state in the workflow process. (Note that to create an iterative step, select the same state in the From State and the To State lists.)

  6. In the Authorized Roles list, select the roles that are allowed to take this step by finishing the assignment. The roles that you select from this list should either match or contain a subset of the roles that you selected for the Assignment Method in the workflow step that immediately precedes this workflow step.

  7. In the Assignment Method section, specify which roles are assigned the asset by selecting among the following options:

    • Retain "From Step" assignees

      If the From State and the To State are different, the first person who takes this step (finishes the assignment) is assigned the asset, even if the previous step assigned the asset to multiple participants.

      If the From State and the To State are the same, every user who was assigned the asset by the last step is assigned the asset again with this step.

    • No assignments; control access with function privs

    • Assign from list of participants

    • Choose assignees when step is taken

      If you select either of the last two options above, select the appropriate roles from the list that is to the right of those options. For definitions of these options, see Determining Steps.

    • Assign to everyone

  8. In the Assignment Deadline section, determine whether the workflow administrator (or other user if you configure the appropriate function privileges) can override the Estimated Time (deadline) set for the state that this step moves the asset to.

  9. (Optional) In the Step Actions list, select one or more step actions that should be called when this step is taken.

  10. (Optional) In the Step Conditions list, select a step condition, if appropriate.

  11. If the step moves the asset from a state in which multiple participants were working on the asset and you want all participants to finish their assignments before the step can complete, select the All Assignees must vote option.

  12. If there are any other steps in this process with the same From State and any of those steps are also all-voting steps (All Assignees must vote is selected), select a Deadlock Action. See Managing Deadlocks and Understanding Delegate Actions.

  13. If this workflow process is used for workflow groups and you want all the assets to progress at the same time to the To State that you selected in step 4 of this procedure, select the Step is group synchronized option. It is recommended that you create only one synchronized step in the process.

  14. Click Save.

    The step is saved and the Steps for Workflow Process form opens.

  15. Click Save.

    The Inspect form opens.

  16. Repeat this procedure for each step—except the end step—to create for this process.

    To create the end step, continue with (Optional) Create the End Step for the Workflow Process.

    To configure function privileges, continue to (Optional) Configure Function Privileges for the Workflow Process.

(Optional) Create the End Step for the Workflow Process

An end step ends the workflow which means that the asset is no longer in a process and no longer has function privileges controlling access to it, if you are using function privileges. Use the following procedure to create an end step for the workflow process:

  1. In the Inspect form of the workflow process, click Edit in the action bar.

    The Edit Process form opens.

  2. Click Add/Edit Steps.

    The Steps for Workflow Process form opens.

  3. Click Add New Step.

    The New Workflow Process Step form opens.

  4. In the Step Name field, enter a unique, meaningful name of up to 64 characters.

    Note:

    The following characters are not allowed in the Name field: double quote ("), less-than sign (<), and greater-than sign (>). Additionally, the name cannot end with a backslash (\).

  5. Configure the states as follows:

    1. In the From State list, select the name of the state that you selected as the To State for the previous step.

    2. In the To State list, select none (end of workflow).

  6. In the Authorized Roles list, select the roles who are allowed to take this step by finishing an assignment. The roles that you select from this list should either match or contain a subset of the roles that you selected for the Assignment Method of the workflow step that immediately precedes this workflow step in the process.

  7. (Optional) In the Step Actions list, select one or more step actions that should be called when this step is taken.

  8. (Optional) In the Step Conditions list, select a step condition, if appropriate.

  9. If the step moves the asset from a state in which multiple participants were working on the asset and you want all participants to finish their assignments before the step can complete, select the All Assignees must vote option.

  10. If there are any other steps in this process with the same From State and any of those steps are also all-voting steps (All Assignees must vote is selected), select a Deadlock Action. See Managing Deadlocks and Understanding Delegate Actions.

  11. If this workflow process is used for workflow groups and you want this step to be performed on all the assets in the group at the same time, select the Step is group synchronized option. it is recommended that you create only one synchronized step in the process.

  12. Click Save.

    The start step is added and the Steps for Workflow Process form opens.

  13. Click Save.

    The Inspect form opens.

If you do not have to configure function privileges, this workflow process is completed. If you do have to configure function privileges, continue to the next procedures.

(Optional) Configure Function Privileges for the Workflow Process

  1. Find the workflow process and open its Inspect form.
  2. In the action bar, click Edit.

    The Edit form opens.

  3. Click Add/Edit Function Privileges at the bottom of the form.

    The Functions for Workflow Process form opens.

  4. Scroll down to the function for which you want to set a privilege.
  5. Click New next to the function.

    The Add Function Privilege form opens.

    Figure 19-10 Add Function Privilege Form

    Description of Figure 19-10 follows
    Description of "Figure 19-10 Add Function Privilege Form"
  6. Select the appropriate state from the State list.
  7. In the Roles list, select the roles that are allowed or not allowed to perform this function when an asset is in this state.
  8. Do either of the following:
    • To allow users with the selected roles to perform the function, select the Allowed check box.

    • To restrict users with the selected roles from performing the function, clear the Allowed check box.

  9. Click Add New.

    The privilege is saved, and the Functions for Workflow Process form opens.

  10. Repeat steps 3 to 8 for each function privilege that you must configure.
  11. After you have configured all of your function privileges, click Save.

    The process is saved. The Workflow Process form opens.

The workflow process is complete.

Testing Your Workflow Process

Before you move your workflow process to the management system and implement it there, test it on your development system.

A complete methodology of testing your process includes:

  • Log in as a user with administrator access and configure start menu items that assign workflow processes to assets, if necessary.

  • Log in as a user who has a role that has been authorized to take the start step of the workflow process. Create an asset, select the workflow process (only if the start menu item does not assign it), and then finish the assignment.

  • Log in as the participant who has the assignment now. Finish the assignment and then log in as the next participant. Continue through the entire workflow in this manner.

  • Verify that the email messages that should be sent are being sent.

  • Verify that your workflow sends the asset through the process correctly.

Moving Your Work

When your workflow is ready to be used by content providers, use the Initialize Mirror Target feature to move your workflow components to the management system. See Migrating a Site from One System to Another.

Clearing Workflow Assignments

People go on vacation, get reassigned to new work groups, and move on to different jobs. What should happen to their workflow assignments in these situations? One option for handling work assignments that cannot be finished by the original assignee is to delegate the assignments to someone else. However, even with the delegate feature, the administrator can still clear assignments from some user's assignment list.

To clear assignments for a user:

  1. In the General Admin tree, expand the Workflow node, and then double-click Clear Assignments.

    The Search for Assignments form opens.

  2. Enter a user name and click Show Assignments.

    The Clear Assignments form opens, showing a list of assets that are currently assigned to that user.

    Figure 19-11 Clear Assignments Form

    Description of Figure 19-11 follows
    Description of "Figure 19-11 Clear Assignments Form"
  3. Select the Clear check box next to each assignment to clear.
  4. Optional: In the Clear assignment comment field, enter a brief explanation of the reason for which you are clearing the selected assignments. The explanation you enter in this field opens in the Action Taken field in the Workflow History section of the asset's Status form.
  5. Do either of the following:
    • If you want the asset to be removed from workflow if it is not assigned to anyone else, select Yes.

    • If you want the asset to remain on the assignment list of any other user who is also assigned the asset, select No.

  6. Click Clear Assignments.

    The Clear Assignments Report summarizing your changes opens.

Creating and Viewing Workflow Reports

Workflow reports are used to view the status of assets in workflow. You can configure the report to show assets by type, by user assignment, by role assignment, workflow state, and deadline.

To create a workflow report, complete the following steps:

  1. Click Workflow in the menu bar. In the displayed form, click Create a Workflow Report.
  2. In the Create Workflow Report form, select the asset type, workflow state, users, roles, or users and roles the asset is assigned to, the assignment deadline, the process deadline, and the final report options.

    None of these options are required. If you do not select any of the options the report will display all assets in workflow.

  3. Click Report to display the report.

The report displays all assets in workflow that meet your selected criteria. Click Save This Workflow Report to save the report parameters to run and view regularly. Click Edit This Workflow Report to change the report criteria and re-run the report.

Creating Workflow Groups

You place assets in a workflow group so you can treat all assets as one work unit. All assets within the group must be approved together before any can move to the next point in workflow.

To create a workflow group, complete the following steps:

  1. Click Workflow in the menu bar. In the displayed form, click Create a Workflow Group.
  2. In the Create Workflow Group form, enter a Name, Description, and a Workflow Process. You must select a workflow process from the pull-down menu before you select the participants.
  3. Click Set Participants... to select the participants in the group. The available participants will depend on the workflow process you selected.

    After you select the participants the Create Workflow Group form re-displays.

  4. Select the roles that can add and remove assets, then select the roles that can edit or delete the workflow group.
  5. Select the group deadlock action.
  6. Click Save. The workflow group is displayed in a new form.

At this point the group is created but it is empty. Click Add to Group to add assets to the group.