Skip Headers
Oracle® Fusion Middleware Managing Oracle WebCenter Content
11g Release 1 (11.1.1)

Part Number E26693-01
Go to Documentation Home
Home
Go to Book List
Book List
Go to Table of Contents
Contents
Go to Master Index
Master Index
Go to Feedback page
Contact Us

Go to previous page
Previous
Go to next page
Next
PDF · Mobi · ePub

7 Managing Workflows

Workflows are used to specify how content is routed for review, approval, and release to the system. This chapter provides overview, tasks, and reference information for using the workflow functionality available with Oracle WebCenter Content Server.

Setting up workflows for a business process can provide several advantages:

This chapter contains the following topics:

7.1 Understanding Workflows

Designing an effective workflow is an iterative process. After initial planning, workflows are refined as the process is implemented. Good planning in the beginning can reduce the amount of rework. For more information on planning, see Section 7.2.

There are three types of workflows:

This section provides details about the steps that make up a workflow:

7.1.1 Workflow Steps

Steps define the process and the functionality of the workflow. Each workflow can include multiple review and notification steps with multiple reviewers to approve or reject the content at each step. For each step in a workflow, a set of users and a step type are defined.

The users defined for a step can perform only the tasks allowed for that step type.

Step Type Description

Contribution

The initial step of a Basic workflow. Administrators define the contributors when the workflow is created.

Auto-Contribution

The initial step of a Criteria workflow. There are no predefined users involved in this step. The contributor who checks in a content item that enters the workflow process automatically becomes part of the workflow.

Review

Users can approve or reject the content; editing is not allowed. You can also specify that the user must approve and sign the content with an electronic signature.

Review/Edit Revision

Users can edit the content if necessary then approve or reject it, maintaining the revision.

Review/New Revision

Users can edit the content if necessary then approve or reject it, creating a new revision.


After a workflow is enabled, it goes through several specific stages:

  • When a content item is approved by the minimum number of reviewers for a particular step, it goes to the next step in the workflow. If the step is defined with 0 approvals required, the reviewers are notified, but the content goes to the next step automatically.

  • If any reviewer rejects the content, it goes back to the most recent Review/Edit Revision or Review/New Revision step. If there is no such step, the content goes back to the original author.

  • Depending on how the edit criteria is defined, the most recent Review/Edit Revision or Review/New Revision step can result in a new revision or an updated revision.

  • A revision can be released:

    • After it exits the workflow: When content is approved at the last step in the workflow, the content item is released to the system.

    • Before it exits the workflow: If a side effect is set that releases a document from edit state, the document is available for indexing, searching, and archiving. Use this primarily for business routing that does not require publishing to the Web, for example an expense report.

  • Generally, if a Basic workflow contains multiple content items, none of them are released to the system until all of the items have been released from completion of the workflow. However, if a content item is released from the edit state as a side effect, that content item can be released without waiting for all items in the Basic workflow.

The standard workflow process can be customized to make it more flexible with jumps, tokens, and aliases. These are discussed fully in Section 7.5.

7.1.1.1 Events

Each step in a workflow has three events: entry, update, and exit.

  • An entry event script is evaluated when entering the step. If the entry event script does not result in a jump or exit, any users, aliases, and tokens are evaluated and e-mail notifications are sent.

  • An update event script is evaluated at various points (for example, during the hourly update cycle or on check in of the revision). Extra exit conditions are evaluated each time the update event script is evaluated.

  • An exit event script is evaluated when a revision has completed the step's approval requirements and the step's extra exit conditions are met.

For more information about Jumps, see Section 7.5.3.1.

Important:

Update and exit event scripts are not run when a revision is rejected. Any code to be evaluated on rejection must be in the entry event script for the step that the rejected content is sent to.

7.1.1.2 Workflow Step Files

The companion file is a text file that tracks the steps the revision has been through and maintains the current values of workflow variables. It is only active for the life of the workflow. Each revision in a workflow has a companion file, which exists while the revision remains in the workflow. When a revision is released from a workflow, its companion file is deleted.

Companion files are in HDA file format, and are named by Content ID (for example, HR_004.hda). Each companion file contains two sets of data:

  • The LocalData Properties section defines the Parent List and other workflow variables.

  • The WorkflowActionHistory ResultSet section contains a record of the steps, workflow actions, and users that have been involved in the revision's workflow history.

To retain a companion file, add the IsSaveWfCompanionFiles configuration variable to the/config/config.cfg file and set the parameter to true. For more information, see the Oracle Fusion Middleware Configuration Reference for Oracle WebCenter Content.

The companion file uses keys to keep track of workflow variables. For example, the following keys define the value of the EntryCount and Last Entry variables for an Editor step in a workflow called Marketing Brochures:

Editor@Marketing Brochures.entryCount=1
Editor@Marketing Brochures.lastEntryTs={ts '2001-05-02 16:57:00'}

The companion file maintains a parent list, which lists the sequence of steps that the revision has been through, starting with the current step and working backward. The parent list is used to determine which step to return to when a file is rejected, when the last step of a workflow is finished, or when an error occurs. For example, the following parent list shows the Marketing Team, Editor, and Graphic Artist steps of the Marketing Brochures workflow:

WfParentList=Marketing Team@Marketing Brochures#Editor@Marketing Brochures#Graphic Artist@Marketing Brochures#contribution@Marketing Brochures

An asterisk (*) in front of a step name in the parent list indicates a jump step.

7.1.2 Workflow Evaluation Process

Figure 7-1 shows a general workflow process.

Figure 7-1 Workflow Process

Surrounding text describes Figure 7-1 .

When a revision enters a workflow step:

  1. The entry script is evaluated.

    • The default entry script that keeps track of the entry count and last entry is updated.

    • Actions (such as additional user notification) are executed.

    • If the jump condition is met and a target step is defined, the revision jumps to another step.

    • If the jump condition is not met, reviewers for the current step are notified that the revision is ready for approval.

    • To avoid infinite loops, the entry script of a previously visited step is ignored. The only exception is when the step has been restarted using the wfCurrentStep(0) symbolic step.

  2. When the required number of reviewers have approved the revision, the exit script is evaluated.

    • If there is no exit script, the revision goes to the next step in the workflow.

    • If an exit script jump condition is met and a target step is defined, the revision jumps to another step.

  3. After the exit script is evaluated, the current action state (the wfAction workflow variable) is set. The following are the possible actions:

    • APPROVE

    • REJECT

    • CHECKIN

    • CONVERSION

    • META_UPDATE

    • TIMED_UPDATE

    • RESUBMIT

  4. As a revision moves through the steps of a workflow, each step is added to the parent list. If the revision revisits a step, the parent list returns to the state it was in when the revision first visited that step. The following table shows an example.

    Revision goes to: Parent list

    Step1

    Step1

    Step2

    Step1#Step2

    Step3

    Step1#Step2#Step3

    Step2

    Step1#Step2


  5. If a revision is rejected, the parent list is checked for the most recent Reviewer/Contributor step, and the revision goes to that step in the workflow.

  6. When a revision completes the last step in a workflow, the parent list is checked for the most recent jump step with a defined return step. If a return step is found, the revision goes to that step. If there are no jump steps in the parent list, or none of the jump steps have a return step defined, the revision exits the workflow.

Content items in a workflow can have the following statuses.

Status Criteria Workflow Basic Workflow

EDIT

The content item was rejected and returned to the initial contribution step.

The content item is in the initial contribution step, or the content item was rejected and returned.

REVIEW

The content item is in the review process.

The content item is in the review process.

PENDING

N/A

The content item completed all the workflow steps, but other content items in the workflow (if included) are not finished.

DONE

The content item in the workflow is finished.

All of the content items are finished.

GENWWW

The content is being converted to Web-viewable format.

The content is being converted to Web-viewable format.

RELEASED

The revision is available in Content Server.

The revision is available in Content Server.


7.1.3 Workflow Participation

E-mail is sent to the participating contributors in a Basic workflow who must check in designated content. E-mail is also sent to reviewers involved in workflow steps. Users can check their necessary actions on the Workflow Content Items page. To access the Workflow Content Items page, choose Content Management then Active Workflows from the Main menu.

Reviewers can review content, reject or approve content, and view information about the content and the workflow. If the content is rejected, the Reject Content Item page opens where the reviewer can enter a message to explain the reason for rejection. The message is sent to the reviewers assigned to the last step allowing a contribution. Those reviewers can then check out the content, edit it and check the content back in. On the Content Check In form, the reviewer should select the Revision Finished Editing box. The content then goes to the next step in the workflow. If the box is not selected, the content remains in Review status and must be approved before moving on through the workflow.

It is good practice to discuss workflows with the people involved so they are aware of the responsibilities they have in the process. More information about workflow participation is available in Oracle Fusion Middleware Using Oracle WebCenter Content.

7.2 Planning a Workflow

This section describes the steps to follow to choose a workflow type and plan the workflow:

Before beginning to design a workflow, evaluate how processes currently operate. For example, if you use e-mail loops to manage information between users on a project, can you incorporate that type of scenario into a workflow design?

Is the workflow being used to validate information? Or is it used for collaboration? What specific problem is it addressing? After you understand the current processes and their shortcomings, you can design the workflow to solve the problem.

Ask the following questions when designing a workflow:

7.2.1 Choosing a Workflow Type

Use a Basic Workflow when you must:

  • Specify an 'ad hoc' workflow, one that does not depend on specific criteria to be enabled.

  • Route multiple content items to go through the same series of steps. The items go through the steps individually, but are not released until all items are finished in the workflow.

  • Notify or remind a user to contribute a content item to the workflow.

  • Specify a workflow that is used infrequently.

  • Set up the review process for a group of related content items.

  • Specify a user to start the workflow. Content can enter a Basic workflow only when a user with Workflow rights starts the workflow.

Use a Criteria Workflow when you must:

  • Have content enter a workflow automatically based on specific metadata values.

  • Route single content items that match specific criteria. Multiple items can be routed, but they do not progress through the workflow as a unit.

  • Set up a standardized review process for individual documents.

  • Specify a frequently-used workflow.

  • Open the workflow to many users. Users do not need Workflow rights for their content to enter a Criteria workflow.

When deciding which type of workflow to use, keep the following key points in mind:

  • If content is checked in with the wrong security group or wrong metadata value, it can enter a Criteria Workflow accidentally.

  • If users are frequently processing content through the same Basic workflow, consider setting up a Criteria workflow to automate the process.

  • Do not use the same or overlapping criteria for multiple workflows. If a content item matches the criteria for multiple workflows, it enters the first workflow in the list.

  • When a content item is in a criteria workflow, it cannot be deleted until the item is released.

7.2.1.1 Security Issues

Keep the following security issues in mind when administering workflows:

  • Each workflow is associated with a security group.

    • For a Criteria workflow, only content items in the same security group enter the workflow.

    • For a Basic workflow, new content items are assigned to the security group of the workflow, and existing content items must belong to the workflow's security group.

  • A workflow can only jump to another workflow in the same security group.

  • The security group of a workflow cannot be changed while a workflow is active but the security group of an item in the workflow process can be changed.

  • Workflow rights and admin permission for the security group of the content are needed to set up a workflow and start it.

  • Workflow templates can be used to initiate contribution steps.

  • Write permission to the workflow's security group is required to be a contributor to the workflow.

7.2.2 Designing a Workflow

To design a workflow:

  1. Draw a flowchart of the workflow. For examples, see Section 7.3.1 and Section 7.4.1.

  2. Verify all the metadata needed for the workflow. If needed, create the metadata before setting up the workflow.

  3. Set up the aliases for the workflow. Alias creation is discussed in Oracle Fusion Middleware Administering Oracle WebCenter Content.

  4. Set up the tokens for the workflow. For more information, see Section 7.5.2.2.

  5. Set up a Basic or Criteria workflow. If workflow templates are available, consider using a template as a starting point. For more information, see Section 7.6.

  6. Set up sub-workflows if necessary.

  7. Set up jumps. For more information, see Section 7.5.3.2.

    • If script templates are available, use them to create the step event scripts.

    • If jumps are used, consider setting up a "master" workflow with sub-workflows for each jump.

  8. Test the workflow.

    • For a Criteria workflow, check in a test document that matches the defined security group and metadata field value.

    • For a Basic workflow, define test content and start the workflow.

    • Simulate as many approval/rejection scenarios as possible.

    • For workflows that contain jumps, simulate as many event scenarios as possible.

    • Include reviewers in the workflow testing to verify that people understand their roles.

7.2.3 Modifying Workflows

Keep these points in mind during workflow design:

You can:

  • Modify the criteria for a Criteria workflow.

  • Add or delete content items from a Basic workflow.

  • Modify step definitions (including reviewers, exit conditions, and events)

You cannot:

  • Change the order of the steps. You can delete steps and re-create them in new locations.

  • Add steps in the middle of the workflow. New steps are always added to the end of the workflow.

  • Delete a content item while it is in a criteria workflow.

  • Archive content items that are in either a basic or criteria workflow.

If you disable a Criteria workflow or cancel a Basic workflow to add or delete steps, any revisions in the workflow are released (Criteria workflow) or deleted (Basic workflow).

The following tips can help when modifying existing workflows. Altering a workflow in use is a time-consuming and difficult process. Careful design before implementation can help avoid rework. These options are considered a temporary correction until the workflow can be rebuilt.

  • Consider the following options to reorder steps in an existing workflow:

    • Create a sub-workflow and add a jump to it from an existing step. This change can be made to an existing step without disabling or canceling the workflow.

    • Add step event scripts to an existing step to define the actions that would normally take place in a separate step. This change can be made to an existing step without disabling or canceling the workflow.

  • If a workflow must be disabled to modify it (for example, to add a step) all revisions are immediately released from the workflow (Criteria workflow) or deleted (Basic workflow). To disable a workflow without releasing content:

    1. Clone the workflow to a static workflow which has the same step sequence as the original workflow but which has no step logic. The content goes into a step and stays there until moved.

    2. Create an update event in the original workflow. This event is triggered by time and pushes the content into the cloned static workflow at the appropriate step.

    3. When the content is out of the original workflow, disable the workflow, make the necessary changes, then re-enable it. Then use the same timed event logic to move the content from the cloned workflow back to the original workflow.

7.3 Creating a Criteria Workflow

Criteria workflows are used to set up a review process for individual documents that enter the workflow automatically when they match predefined criteria. For example, any time a new purchase order is generated, it might be automatically routed to specific reviewers for approval.

A Criteria workflow includes the following:

Sub-workflows are set up using the same procedure as Criteria workflows with a few minor exceptions which are noted in the procedure for setting up Criteria workflows.

This section discusses the following topics:

7.3.1 Criteria Workflow Process

The following steps briefly explain the Criteria workflow process:

  1. A user with Workflow rights sets up the Criteria workflow by defining the following:

    • Security group

    • Metadata field and value (for example, ContentType matches PurchaseOrder). You can use fields of type Text or Long Text.

    • Review steps and reviewers for each step

    • The number of approvals required for each step. For example, must all reviewers approve it before it can move to the next step?

    • Any aliases and the people in the alias group

    • Any tokens needed

  2. A user with Workflow rights enables the Criteria workflow.

  3. When content is checked in that matches the defined security group and metadata field value, the content enters the workflow.

  4. Reviewers for the first step receive e-mail that the revision is ready for review.

  5. The reviewers approve or reject the revision.

    • If the step is a reviewer step, the reviewers can optionally sign and approve the content item revision without modification (changing the document produces a different identifier and invalidates any existing electronic signatures).

    • If the step is a reviewer/contributor step, the reviewers can check out the revision, edit it, and check it back in before approving it. For example, editors can alter the content of an item in the workflow.

    • If a user rejects the revision, the workflow returns to the previous contribution step, and the users for that step are notified by e-mail.

    • When the minimum number of users have approved the revision, it goes to next step. If the minimum number of approvals is 0, the revision moves to the next step automatically.

  6. When all steps are complete, the revision is released to the system.

    Figure 7-2 Criteria Workflow Process

    Surrounding text describes Figure 7-2 .

7.3.1.1 Criteria Workflow Tips

Each Criteria workflow must have unique criteria. If a content item matches the criteria for two workflows, it enters the first one in the list of defined workflows.

  • All users assigned to the Criteria workflow must have Read permission to the selected security group. Contributors must have Write permission to the selected security group to check the revision in and out.

  • You cannot add or delete steps while a Criteria workflow is enabled.

  • You cannot delete or archive a content item while it is in a criteria workflow.

  • Any content item checked in while a Criteria workflow is disabled bypasses the workflow process and is released to the system.

  • Disabling a Criteria workflow releases revisions in the workflow to the system.

  • A Criteria workflow can use jumps to sub-workflows and other Criteria workflows in the same security group, and can jump to other steps in the same workflow.

  • Consider making at least one step in the workflow a Reviewer/Contributor step so rejected revisions go to that step rather than back to the original author.

  • If the security group of an item does not match the security group of the workflow, the item does not enter the workflow.

  • Ensure that the criteria is different from other Criteria workflow.

  • If Content ID is used for the Field and if an Oracle database is used, enter all uppercase characters for the Value. All other fields can have mixed case.

  • If ContentID is used as the Field, click Select below the Value field to choose an existing content item.

  • Enter zero (0) in the At least this many reviewers field to notify reviewers that the revision has reached the step and to pass it on to the next step automatically. Reviewers cannot approve, reject, or edit the revision at that step.

7.3.2 Setting Up a Criteria Workflow

To create a Criteria workflow or sub-workflow:

  1. Choose Administration then Admin Applets from the Main menu. Choose Workflow Admin. Click the Criteria tab.

  2. Click Add.

  3. On the New/Edit Criteria Workflow page, enter a name in the Workflow Name field. Maximum length is 30 characters. Special characters (; @ &, and so on) are not allowed. You cannot change the workflow name after the workflow is created.

  4. Enter a detailed description for the workflow in the Description field.

  5. Select the Security Group from the list.

  6. Select an option from Original Author Edit Rule to specify if the original author can edit the revision or create a new revision if the item is rejected.

  7. To use a workflow template, select the Use Template check box and select the template name. This box is displayed only if a template currently exists. For more information, see Section 7.6.

  8. To create a Criteria workflow, select the Has Criteria Definition check box. To create a sub-workflow, deselect the check box.

  9. For a Criteria workflow, define the criteria by choosing the appropriate Field, Operator, and Value. Field values include Content ID, Author, Type, Account and any custom metadata of type Text or Long Text.

  10. Click OK.

  11. If a template was not used to create steps or to add another step, click Add in the right pane of the Workflow Admin page.

  12. On the Add New/Edit Step page, enter an appropriate Name for the step. You cannot change the name after the step is created. The name is usually descriptive of the step (for example, EditorialReview or TechnicalReview).

  13. To require that a reviewer provide credentials for an electronic signature, select Requires signature on approval. This option is available only if the Electronic Signatures component is enabled.

    An electronic signature uniquely identifies the contents of the file at a particular revision and associates the signature with a particular reviewer. If selected, the standard Approve action is replaced by the Sign and Approve action in the list of step options provided to the reviewer.

  14. Enter a Description for the step.

  15. Specify the authority level of the users for the step:

    • Users can review the current revision: Users can approve or reject the revision but cannot edit the revision.

    • Users can review and edit (replace) the current revision: Users can edit the revision, approve it, or reject it. An edit does not update the revision.

    • Users can review the current revision or create new revision: Users can edit the revision, approve it, or reject it. An edit updates the revision. This option preserves the original content and provides an audit trail of changes.

  16. Select the type of users to be added to the step. Multiple types can be defined:

    • To add a group of users defined by an alias, click Add Alias. On the Add Alias to Step page, choose the alias from the displayed list.

    • To add individual user logins, click Add User. On the Add User to Step page:

      • To narrow the list of users, select the Use Filter check box, click Define Filter, select the filter criteria, and click OK.

      • To select a range of users, click the first user, then press and hold Shift and click the last user in the range.

      • To select users individually, press and hold Ctrl and click each user name.

    • To add a variable user defined by a token, click Add Token. For information about creating tokens, see Section 7.5.2.2.

  17. Click OK.

  18. Click the Exit Conditions tab.

  19. Specify how many reviewers must approve the revision before it passes to the next step.

    • To require approval by all reviewers, select All reviewers.

    • To specify a minimum number of reviewers who must approve the revision, select At least this many reviewers and enter the number.

  20. Typically, exit conditions are useful when metadata could be changed by an external process during the workflow step. Use the following instructions if the step requires additional exit conditions to pass to the next step:

    1. Select the Use Additional Exit Condition check box.

    2. Click Edit.

    3. On the Edit Additional Exit Condition page, select a workflow condition or a metadata field from the Field list.

    4. Select an operator from the Operator list. Operator is a dependent choice list that shows operators associated with the Field.

    5. Select a value from the Value list. Value is a dependent list based on the option chosen as the Field.

    6. Click Add to add the conditional statement to the Condition Clause. The clause appears in the Condition Clause box. You can append multiple clauses with AND statements.

    7. Repeat for as many conditions as required. To modify an expression, select it in the Condition Clause box, change the Field, Operator, or Value, and click Update.

    8. To modify the condition expression, select the Custom Condition Expression check box and edit the script (for example, use OR not AND for a condition). The additional exit conditions must be Idoc Script statements that evaluate to true or false. Do not enclose the code in Idoc Script tags <$ $>.

      Caution:

      If Custom Condition Expression is deselected, the expression reverts to its original definition and all modifications are lost.

    9. Click OK.

  21. If the workflow requires conditional steps or special processing, click the Events tab and add the appropriate scripts. For more information, see Section 7.5.3.2.

  22. Click OK.

  23. Add, edit, and delete steps as necessary to complete the workflow.

    • To add another step to the workflow, repeat steps 11 through 22.

    • To edit an existing step, select the step and click Edit.

    • To delete an existing step, select the step and click Delete.

  24. Ensure that the correct workflow is selected in the left pane, and click Enable.

  25. On the confirmation page, click Yes to activate the selected workflow.

7.3.3 Changing a Criteria Workflow or Sub-workflow

If a Criteria workflow is disabled to add or delete steps, any revisions in the workflow are released.

To change an existing Criteria workflow or sub-workflow:

  1. Choose Administration then Admin Applets from the Main menu. Choose Workflow Admin. Click the Criteria tab.

  2. Select the workflow to change in the left pane.

  3. To add or delete steps, click Disable.

  4. Click Add, Edit, and Delete in the left and right panes to change the following:

    • workflow description

    • security group

    • type of workflow (Criteria or sub-workflow)

    • criteria

    • step description

    • type of step (reviewer, contributor same revision, contributor new revision)

    • users

    • events

    • number of approvals required

    • exit conditions

    Users can be added to a step while the Criteria workflow is enabled, but if any revisions are currently at that step in the workflow, the new users are not notified immediately. They are notified after the scheduled workflow system event occurs and performs a TIMED_UPDATE on all items in the workflow.

  5. If the workflow is disabled, ensure that the correct workflow is selected in the left pane and click Enable.

  6. On the confirmation page, click Yes to activate the selected workflow.

7.3.4 Disabling a Criteria Workflow or Sub-workflow

To disable a criteria workflow or sub-workflow:

  1. Choose Administration then Admin Applets from the Main menu. Choose Workflow Admin. Select the Criteria tab.

  2. Select the workflow.

  3. Click Disable.

  4. If any content items are still in the workflow process, you are notified that all of the content revisions will be released. If you do not want to release the content, click No to cancel the operation. Click Yes to release any content and disable the workflow.

    The status of the workflow changes to Disabled.

7.4 Creating a Basic Workflow

A Basic workflow defines the review process for specific content items. It is set up and initiated manually, and does not require you to define criteria for content to enter the workflow.

A Basic workflow includes the following:

This section discusses the following topics:

7.4.1 Basic Workflow Process

The following steps explain the Basic workflow process:

  1. A user with Workflow rights sets up the Basic workflow by defining the following items:

    • Content: Either create new content or select existing content. After going through the workflow, new content is released to the system at revision 1, and existing content is released to the system at the next revision number for that content item.

    • Initial contributors: Specify the list of user who can contribute content.

    • Review steps: Specify the reviewers for each step and number of approvals required for each step.

  2. A user with Workflow rights starts the Basic workflow by enabling it.

  3. An e-mail is sent to the contributors.

  4. Any of the contributors can check out then check in a file for each content item in the workflow.

  5. Reviewers for the first step are notified by e-mail that the revisions are ready for review.

  6. The reviewers approve or reject the revisions.

    • If the step permits editing, the reviewers can check out the revisions, edit them, and check them back in before approving it.

    • If a user rejects a revision, the revision returns to the previous contribution step, and the users for that step are notified by e-mail.

    • When the minimum number of users have approved the revision, it goes to next step. (If the minimum number of approvals is 0, the revision moves to the next step automatically.)

  7. Generally, if a Basic workflow contains multiple files, none of them are released to the system until all of the files have been released from completion of the workflow. Completed content items stay in PENDING status until the last revision is approved. However, if you release a content item from the edit state as a side effect, you can release that content item without waiting for all items in the Basic workflow.

  8. When all steps are complete and all revisions are approved, the revisions are released to the system.

Figure 7-3 Basic Workflow Process

Surrounding text describes Figure 7-3 .

7.4.2 Basic Workflow Tips

  • For new content, the Content ID defined in the workflow is the Content ID applied when the revision is released to the system. The Content ID cannot be changed.

  • A content item cannot be added to multiple basic workflows or an error occurs and the workflow is not enabled.

  • New content is assigned to the security group of the Basic workflow.

  • The security group of an existing revision must match the security group of the Basic workflow.

  • All users assigned to the Basic workflow must have Read permission to the selected security group. Contributors must have Write permission to the selected security group to edit revisions.

  • Review steps cannot be added, edited or deleted while a Basic workflow is active.

  • If an active workflow is canceled, any revisions in the workflow are deleted from the system. Any edits made to the files are lost unless they have also been saved on a local hard drive.

  • An inactive Basic workflow can be reused, but it must be started manually each time.

  • A Basic workflow can use jumps, but only to other steps in the same workflow. A Basic workflow cannot jump to a sub-workflow.

7.4.3 Setting Up a Basic Workflow

Keep these points in mind before creating a Basic workflow:

  • All users assigned to the workflow must have Read permission to the selected security group, and Contributors must have Write permission.

  • If using a template, change the reviewers if they are different from those defined in the selected template.

  • Do not add a content item to multiple basic workflows or an error occurs and the workflow is not enabled.

  • Enter zero (0) in the At least this many reviewers field to notify reviewers that the revision has reached the step. Reviewers cannot approve, reject, or edit the revision at that step. The workflow passes to the next step automatically.

To create a Basic workflow:

  1. Display the Workflow Admin: Workflows tab. The default tab view is that of a Basic workflow.

  2. Click Add.

  3. On the Add New/Edit Workflow page, enter a name in the Workflow Name field. The Workflow Name has a maximum field length of 30 characters and cannot contain special characters (; @ &, and so on). The name cannot be changed after the workflow is created.

  4. Enter a detailed description for the workflow in the Description field.

  5. Select the Security Group from the list to which the content items in this workflow belong.

  6. Select an option from Original Author Edit Rule to specify if the original author can edit the existing revision or create a new revision if the content item is rejected.

  7. To use a template, select the Use Template check box and select the template name. This box is displayed only if a template exists. For more information, see Section 7.6.

  8. Click OK.

  9. To add a new content item to the workflow, click New.

    On the Add Content to Workflow (New Content) page:

    1. Enter a Content ID for the new content item. The Content ID cannot be changed. To change a Content ID, delete the content item from the list and re-add it. If using an Oracle database, all Content IDs are converted automatically to uppercase letters.

    2. Click OK.

  10. To add an existing content item to the workflow, click Select.

    On the Add Content to Workflow (Existing Content) page:

    • To narrow the list of content items, specify criteria for the filter, release date or both.

    • To select a range of content items, click the first content item, then press and hold Shift and click the last content item in the range.

    • To select content items individually, press and hold Ctrl and click each content item.

    Existing content items must have the same security group as the workflow.

  11. Repeat steps 9 and 10 as necessary to add content items to the workflow.

  12. Define one or more contributors for the initial contribution step. You can define multiple types of users for the contribution step.

    • To add a group of users defined by an alias, click Add Alias to open the Add Alias to Workflow page.

    • To add individual user logins, click Add User to open the Add User: Basic Workflow page.

      • To narrow the list of users, select the Use Filter check box, click Define Filter, select the filter criteria, and click OK.

      • To select a range of users, click the first user, then press and hold Shift and click the last user in the range.

      • To select users individually, press and hold Ctrl and click each user name.

  13. If a template was not used to create review steps, or to add another step, click Add in the right pane near the Steps box.

  14. On the Add New/Edit Step page, enter an appropriate Name for the step. You cannot change the name after the step is created. The name is usually descriptive of the step (for example, EditorialReview or TechnicalReview).

  15. To require that a reviewer provide credentials for an electronic signature, select Requires signature on approval. This option is available only if you enabled the Electronic Signatures component.

    An electronic signature uniquely identifies the contents of the file at a particular revision and associates the signature with a particular reviewer. If you select this option, the standard Approve action is replaced by the Sign and Approve action in the list of step options provided to the reviewer.

  16. Enter a Description for the step.

  17. Specify the authority level of the users for the step.

    • Users can review the current revision: Users can approve or reject the revision.

    • Users can review and edit (replace) the current revision: Users can edit the revision, approve it, or reject it. Any edit does not update the revision of the content item.

    • Users can review the current revision or create new revision: Users can edit the revision, approve it, or reject it. Any edit updates the revision of the content item which preserves the original content and provides an audit trail of changes.

  18. Select the type of users to be added to the step. Multiple types of user can be defined:

    • To add a group of users defined by an alias, click Add Alias to open the Add Alias to Step page.

    • To add individual user logins, click Add User to open the Add User: Basic Workflow page. To narrow the list use the Use Filter check box; to select a range of users, click the first user, then press and hold Shift and click the last user name in the range. To select users individually, press and hold Ctrl and click each user name.

    • To add a variable user defined by a token, click Add Token. For more information, see Section 7.5.2.2.

    • Click the Exit Conditions tab.

    • Specify how many reviewers must approve the revision before it passes to the next step.

    • To require approval by all reviewers, select All reviewers.

    • To specify a minimum number of reviewers who must approve the revision, select At least this many reviewers and enter the number.

  19. Typically, exit conditions are useful when metadata could be changed by an external process during the workflow step. Use the following instructions if the step requires additional exit conditions to pass to the next step:

    1. Select the Use Additional Exit Condition check box.

    2. Click Edit.

    3. On the Edit Additional Exit Condition page, select additional criteria from lists.

    4. Select a workflow condition or a metadata field from the Field list.

    5. Select an operator from the Operator list. Operator is a dependent list that shows operators associated with the Field.

    6. Select a value from the Value list. Value is a dependent list based on the option chosen as the Field.

    7. Click Add to add the conditional statement to the Condition Clause. The clause appears in the Condition Clause box. You can append multiple clauses with AND statements.

    8. Repeat for as many conditions as required. To modify an expression, select it in the Condition Clause box, change the Field, Operator, or Value, and click Update.

    9. To modify the condition expression, select the Custom Condition Expression check box and edit the script (for example, use OR not AND for a condition). The additional exit conditions must be Idoc Script statements that evaluate to true or false. Do not enclose the code in Idoc Script tags <$ $>.

      Caution:

      If Custom Condition Expression is deselected, the expression reverts to its original definition; all modifications are lost.

    10. Click OK.

  20. If the workflow requires conditional steps or special processing, click the Events tab and add the appropriate scripts. For more information, see Section 7.5.3.2.

  21. Click OK.

  22. Add, edit, and delete steps as necessary to complete the workflow.

    • To add another user to the initial contribution step, repeat step 12.

    • To delete a user from the initial contribution step, click Delete.

    • To add another review step to the workflow, repeat steps 13 through 21.

    • To edit an existing review step, select the step and click Edit.

    • To delete an existing review step, select the step and click Delete.

  23. Ensure that the correct workflow is selected in the left pane, and click Start.

  24. On the Start Workflow page, enter a message to be sent to the contributors.

  25. Click OK.

7.4.4 Changing a Basic Workflow

To change an existing Basic workflow:

  1. Display the Workflow Admin: Workflows tab.

  2. Select the workflow to change in the left pane.

  3. To change the workflow security group or the number of review steps in an active workflow, first click Cancel to cancel the workflow.

  4. Click Edit in the left pane to change the workflow description or the security group.

  5. Click New then Select then Delete in the Content pane to add or delete content from the workflow.

  6. Click Add Alias then Add User then Delete in the Contributors pane to add or delete contributors from the initial contribution step.

    Caution:

    Content items can be changed in a Basic workflow after it has started, but the contributors are not notified automatically. Contributors can be changed after the workflow is started, but any new contributors are not notified immediately.

  7. Click Add then Edit then Delete in the Steps pane to change the following:

    • Requires signature on approval (optional Electronic Signatures option)

    • Step description

    • Type of step (reviewer or reviewer/contributor)

    • Users

    • Events

    • Number of approvals required

    • Exit conditions

7.5 Customizing Workflows

Tokens and jumps are used to customize workflows to accommodate different business scenarios. A token defines variable users in a workflow and a jump branches a workflow to a different side effect.

This section describes how to set up and use tokens and jumps. It discusses the following topics:

7.5.1 Idoc Script Functions and Variables

Jumps and tokens are created using Idoc script. The interfaces create the correct syntax and usage for you when you create tokens and jumps. However, you can customize your scripts using the following Idoc Script functions. For more information about usage, see Oracle Fusion Middleware Developing with Oracle WebCenter Content.

Idoc Script Functions

Function Description

wfAdditionalExitCondition

Retrieves the exit condition defined for the current step.

wfAddUser

Adds a user, alias, or workflow token to the list of reviewers for a workflow. Use this function only inside a token.

wfCurrentGet

Retrieves a local state value from the companion file.

wfCurrentSet

Sets the local state value of a key in the companion file.

wfCurrentStep

Retrieves the name of a step relative to the current step.

wfDisplayCondition

Retrieves the exit condition for a workflow step.

wfExit

Exits a workflow step. Can be used to exit the workflow.

wfGet

Retrieves a state value from the companion file.

wfGetStepTypeLabel

Takes an internal workflow step value and turns it into a human-readable label.

wfIsReleasable

Indicates if the document is released (as far as the workflow is concerned).

wfJumpMessage

Defines a message to be included in the notification e-mail that is issued when a jump is entered.

wfLoadDesign

Used to retrieve information about the existing steps in a workflow or about the exit conditions in a workflow.

wfNotify

Sends an e-mail to a specified user, alias, or workflow token.

wfReleaseDocument

Causes a workflow to release all outstanding document revisions for a document currently being locked by the workflow.

wfSet

Sets a key with a particular value in the companion file.

wfUpdateMetaData

Defines a metadata value for the current content item revision in a workflow.


Idoc Script Variables

Variable Description

wfAction

The action currently being performed on the revision.

wfJumpEntryNotifyOff

Turns on/off the jump notification.

wfJumpName

The name of the current jump.

wfJumpReturnStep

The name of the step in the parent workflow that the revision returns to when exiting a workflow after the current jump.

wfJumpTargetStep

The name of the step where the revision jumps if the conditions are met.

wfMailSubject

Defines the subject line of a workflow e-mail notification.

wfMessage

Defines a message to be included in a workflow e-mail notification.

wfParentList

List of the workflow steps that the revision has visited.

wfStart

Sends the revision to the first step in the current workflow.


7.5.2 Workflow Tokens

Use a token for the following purposes:

  • Add a variable to a workflow which is interpreted to be a specific user or class of user when the workflow is run.

  • Include users and aliases in workflow jumps.

  • Define users with conditional statements.

A token assignment is unique and local to each document in a workflow. The logic used to assign the token of one document does not affect other documents in the workflow.

Several sample workflow tokens are included which can be used as-is, or can be modified.

Important:

If a token does not resolve to any valid user names, the token is ignored. If no valid users are defined for a step, the revision moves to the next step in the workflow. For this reason, it is a good idea to identify at least one defined user for each step.

This section discusses the following information about tokens:

7.5.2.1 Token Syntax

The Idoc Script function for tokens, wfAddUser, takes two parameters:

  • User: The metadata field, alias name, or a variable that resolves to a user name or alias.

  • Type: The type of token, either user or alias.

All Idoc Script commands begin with <$ and end with $> delimiters. For example:

<$wfAddUser(dDocAuthor, "user")$>
<$wfAddUser("MktTeam", "alias")$>
<$wfAddUser("myUserList", "alias")$>

For more information about Idoc Script syntax and usage, see Oracle Fusion Middleware Configuration Reference for Oracle WebCenter Content.

7.5.2.2 Creating, Editing, or Deleting a Token

To create a token to represent one or more unspecified users, such as the document author:

  1. Choose Administration then Admin Applets from the Main menu. Choose Workflow Administration. Choose Tokens from the Options menu.

  2. On the Workflow Tokens page, click Add.

  3. On the Add/Edit Token page, enter a token name in the Token Name field. You cannot change the Token Name after you create the token. Try to use a descriptive name for the token (for example, GetOriginalAuthor, or AuthorManager).

  4. Enter a detailed description in the Description field.

  5. Click Add.

  6. On the Add Token User page, select User or Alias.

  7. Enter a metadata field that will resolve to a user or alias.

    • To specify the original author of the content item, enter dDocAuthor.

    • To specify an alias, type the alias name. See the Screen Aliases tab on the User Admin page for a list of defined aliases.

  8. Click OK. The Idoc Script containing the value you specified is shown in the User window.

  9. Repeat steps 5 through 8 to add another user or alias.

  10. To create a conditional token, edit the Users field. For an example, see Section 7.5.2.3.

  11. Click OK.

To change an existing workflow token, follow the previous steps and select the token to change. Click Edit. Make any necessary changes and click OK.

To delete a token, select the token from the list and click Delete.

7.5.2.3 Token Examples

The following examples illustrate how to use tokens in workflows.

Example 7-1 Original Author the Only Contributor

This example assumes that the original author is the only contributor for the file. Example 7-2 addresses the situation where different authors could check out and check in the file during the workflow process.

To notify the original author of each file when their content is released from a workflow into the system, first create a token that corresponds to the Author metadata field, which is called dDocAuthor in Idoc script. When setting up the workflow, create a notification step (0 approvals required) and select the token as the user for that step. For example:

<$wfAddUser(dDocAuthor, "user")$>

Example 7-2 Workflow with Reviewer/Contributor Steps

If a workflow includes Reviewer/Contributor steps, a user other than the original contributor could check in a revised file, and the dDocAuthor would no longer be the original author. In this case, you could set the OriginalAuthor variable in the companion file using custom script in the first workflow step, and specify the custom variable in the token instead of using dDocAuthor.

The event script in the first step might look like the following:

<$wfSet("originalContributor", dDocAuthor)$>
<$wfSet("type", user)$>

And the token script for the notification step would look like:

<$wfAddUser(wfGet("originalContributor"), wfGet("type"))$>

Example 7-3 Reviewers Selected Based on Jump Criteria

One typical use for tokens is to select reviewers as needed, or based on the conditions of a jump. Suppose you have a workflow set up for standard routing of all marketing materials through the Marketing department. However, you want any changes to your company catalogs to also be reviewed by the Distribution department.

To do this, create a jump that adds a token to the list of reviewers whenever the Type is catalog. For example:

<$wfAddUser("Dist_Dept", "alias")$>

Example 7-4 Conditional Token

Rather than creating a jump script for the previous example, you could define a conditional token that adds the Dist_Dept alias whenever the Type is catalog. For example:

<$if dDocType like "catalog"$>
  <$wfAddUser("Dist_Dept", "alias")$>
<$endif$>

Example 7-5 Token Specifying Management Chain

Another common use for tokens is specifying the current user's manager as a reviewer. (The manager attribute must be specified as a user information field in Content Server, or as a user attribute in an external directory such as LDAP or ADSI.) For example:

<$wfAddUser(getUserValue("uManager"), "user")$>

7.5.3 Workflow Jumps

Jumps are used to customize workflows. They are usually a conditional statement, written in Idoc Script.

Typical uses of jumps include:

  • Specify multiple metadata fields as the criteria to enter a workflow.

  • Take action on content automatically after a certain amount of time has passed.

  • Define different paths for files to move through the same workflow depending on metadata and user criteria.

  • Release a workflow document before approval by using the side effect: Release document from edit state.

The following is an example of a jump that exits the workflow if the author is sysadmin:

<$if dDocAuthor like "sysadmin"$>
  <$wfSet("wfJumpName", "Entry step")$>
  <$wfSet("wfJumpTargetStep", wfExit(0, 0))$>
  <$wfSet("wfJumpEntryNotifyOff", "0")$>
<$endif$>

In most cases, a jump includes a conditional statement. However, a jump can consist of non-conditional code, such as the following:

<$wfSet("custom_wf_variable", new_value)$>
  <$wfSet("wfJumpTargetStep", step_1)$>

This type of jump can be used to execute code or move a revision to another step automatically.

This section discusses the following topics about jumps:

7.5.3.1 Jumps and Events

As mentioned in Section 7.1.1.1, each step in a workflow has an entry, update, and exit event.

A script can be created with one or more jumps for any or all of the events in a step. Any Idoc Script defined for an event is evaluated at a specific time that depends on the type of event:

  • An entry event script is evaluated upon entering the step. Every time a step is entered, a default script is evaluated in addition to any user-defined custom script. The default script keeps track of the number of times the step has been entered (entryCount) and the last time the step was entered (lastEntryTs).

    If the entry event script does not result in a jump or exit, any users, aliases, and tokens are evaluated, and e-mail notifications are sent.

  • An update event script is evaluated and triggered by a state change of the content, such as the workflow update cycle, the update of the revision's metadata or approval or check in of the revision.

    Extra exit conditions are evaluated each time the update event script is evaluated.

  • An exit event script is evaluated when a revision has completed the step's approval requirements and the step's extra exit conditions are met.

By default, the workflow update cycle occurs hourly. The cycle time can be increased in increments of one hour (using the WorkflowIntervalHours configuration setting), but cannot be reduced to less than one hour. To have update scripts evaluated more often or in response to other events, initiate a metadata update cycle without changing any metadata.

Figure 7-4 Jumps and Events

Surrounding text describes Figure 7-4 .

Within a single workflow, when a reviewer rejects a revision the content item is routed back to the most recent contribution step. However, when a jump is made to a sub-workflow or other workflow and content is rejected there, different behavior occurs. The process returns to the parent workflow, not to the previous contribution step.

Important:

Update and exit event scripts of the current step are not run when a revision is rejected. Any code that is to be evaluated upon rejection must be located in the entry event script for the step that the rejected file is sent to.

Side effects are the actions that take place when a revision in a workflow step meets the jump condition. Side effects can include:

  • Jump to another step in the same workflow

  • Jump to a step in a sub-workflow or other Criteria workflow (for Criteria workflows only)

  • Notify users

  • Exit the workflow

  • Set state information in the companion file

  • Release a workflow document before approval

A jump can include a target step, which tells the workflow where to go to if the content meets the jump condition. The following is an example of a target step that sends the content to the next step in the workflow

<$wfSet("wfJumpTargetStep", wfCurrentStep(1))$>

A jump can also include a return step, which tells the workflow where to go if the content is returning from another workflow. The following is an example of a return step that sends the content to the next step in the workflow:

<$wfSet("wfJumpReturnStep", wfCurrentStep(1))$>

A step name variable, step_name@workflow_name, is assigned to each step in a workflow. There are two ways to reference a step in a jump:

  • Explicit reference is made to a specific step name, such as Editor@Marketing Brochures.

  • Symbolic reference is made relative to the current step and workflow, such as wfCurrentStep(-1) (previous step) or wfStart (first step in the workflow).

    Tip:

    Use symbolic references rather than explicit step names whenever possible especially when creating a script template.

The entry count variable, entryCount, keeps track of how many times a step has been entered and is part of the default entry script that is updated each time a step is entered. The following is an example of how an entry count variable is used in a conditional statement:

<$if entryCount = 1$>

The last entry variable, lastEntryTs, keeps track of when the step was last entered and is part of the default entry script that is updated each time a step is entered. The following is an example of how the last entry variable is used to specify that action should occur if the step has not been acted on within seven days:

<$if parseDate(wfCurrentGet("lastEntryTs")) < dateCurrent(-7)$>

7.5.3.2 Creating a Jump

Before creating jumps, draw a flowchart and work out all the possible jump scenarios. A recommended method of structuring jumps is to create a main workflow with steps that jump to sub-workflows.

After determining what jumps must occur within a workflow, set up the jumps then test them. You can create jumps directly in an existing workflow, or you can create script templates for jumps to be reused in different workflows.

Figure 7-5 Jump Flowchart

Surrounding text describes Figure 7-5 .

To create a jump:

  1. Create the workflow that contains jumps. For more information, see Section 7.3.2 or Section 7.4.3.

  2. On the Workflow Admin page, select the workflow. Click the Criteria tab or the Workflows tab (depending on the type of workflow).

  3. In the Steps pane, click Add or select the step to include the jump and click Edit.

  4. On the Add New/Edit Step page, click the Events tab.

  5. Click Edit next to the event (entry, update, or exit) containing the jump.

    • If a script template does not exist, use the Script Properties page to add properties.

    • If a script template exists, on the Edit Script for StepName page, select an editing option. To create the script from a blank page, select Create New. To create the script from a script template, select Use Script Template then select a template from the list.

  6. Click OK.

To test the side effects of a jump:

  1. On the Jumps tab, click Add, or select an existing jump and click Edit.

  2. For a new jump, on the Edit Script for StepName page, enter a jump name. You cannot change the Jump Name after you create the jump. Try to use a meaningful, descriptive name.

  3. If the jump must specify a return point, select the Has Return Point check box and select a return point from the list. The possible options are: Current Step, Next Step, Previous Step.

  4. If the reviewers for this step should not be notified when the jump is entered, select the Do not notify users on entry check box.

  5. If the content item is released before approval, select the Release document from edit state check box.

  6. Enter any custom side effects in the Custom Effects field. For examples, see Section 7.5.3.4.

  7. If the reviewers are notified when the jump is entered, click the Message tab and enter the notification message.

  8. Click OK. The Edit Script page is re-displayed.

To set up conditional statements:

  1. Select a metadata field from the Field list. This value is the workflow conditions or metadata field to be evaluated.

  2. Select an operator from the Operator list. Operator is a dependent list that shows only the operators associated with the Field.

  3. Select a value from the Value list. Value is the value associated with the specified metadata field.

  4. Click Add to add the conditional statement to the script.

To complete the jump:

  1. If the jump must specify a target step:

    • To specify a specific step, click Select, then select the workflow and step name on the Select Target Step page. The target step name is displayed in the target step area.

    • To select a symbolic step, such as the current step or exit the workflow, select the step from the Target Step list.

  2. To modify the script that was just created, click the Custom tab, select the Custom Script Expression check box, and edit the code.

    Caution:

    If Custom Script Expression is deselected, the expression reverts to its original definition. All modifications are lost.

To test the script:

  1. Click the Test tab.

  2. Click Select.

  3. To narrow the content list, on the Content Item View page, select the Use Filter check box, click Define Filter, select the filter criteria, and click OK.

  4. Select a content item to test and click OK. Check in and process a test document so that it is in the workflow and at the step you are adding the jump to, then select that content item for testing. If the selected content item is not currently in a workflow, you can still use it to test the script, but it is treated as if it were newly in the workflow.

  5. Click Load Item's Workflow State.

    If the selected content item is in a workflow, the companion file is loaded in the Input Data field.

  6. Click Test Script.

  7. The test results are displayed in the Results field.

    • The value of each parameter in the script is displayed.

    • If any Idoc script errors occur, they are displayed with the script containing the errors.

  8. To save the script, click OK.

  9. Continue adding jumps as needed to different steps.

7.5.3.3 Changing a Jump

To change an existing jump:

  1. Select the workflow on the The Workflow Admin page or the Workflow Admin: Workflows tab.

  2. In the Steps pane, select the step that includes the jump to be changed.

  3. Click Edit in the Steps pane.

  4. On the Add New/Edit Step page, click the Events tab.

  5. To delete a jump, click Clear in the corresponding event pane. To change a jump, click Edit in the corresponding event pane.

  6. On the Edit Script for StepName page, select an editing option:

    • To edit the existing script, select Edit Current.

    • To create a script, select Create New.

    • To use a script template, select Use Script Template then select a template from the list.

  7. On the Script Properties page, click Add, Edit, or Delete in the Jumps pane to change the jump side effects.

  8. Use the Field, Operator, Value fields and Add and Update buttons in the Script Clauses pane to change the conditional statements for the jumps.

  9. Use the Target Step list to change the target step for the jump.

  10. To change the automatically generated script, click the Custom tab, select the Custom Script Expression check box, and edit the code.

    Caution:

    If you clear the Custom Script Expression check box, the expression reverts to its original definition and modifications are lost.

  11. Test the script before saving it.

  12. Click OK to save the changes.

7.5.3.4 Jump Examples

The following examples describe how to set up different types of jumps.

Example 7-6 Metadata Criteria Jump

Suppose you have a Criteria workflow called Marketing Brochures that is defined with the Marketing security group and the MktBrochure content type. However, any brochures submitted by a graphic artist do not have to go through the first step, which is graphics department approval. You would use the Edit Script page to create the following entry event script for the first step.

<$if dDocAuthor like "bjones" or dDocAuthor like "sjames"$>
  <$wfSet("wfJumpName", "BypassGraphics")$>
  <$wfSet("wfJumpTargetStep", wfCurrentStep(1))$>
  <$wfSet("wfJumpEntryNotifyOff", "0")$>
<$endif$>

To change the automatically generated conditional statement from and to or, you must edit the script on the Custom tab of the Edit Script page.

Example 7-7 Time-dependent Jump

Suppose you want to limit the review period to one week. If the revision has not been approved or rejected, you want to notify the reviewers and process the revision through a sub-workflow called ApprovalPeriodExpired. You would use the Edit Script page to create the following update event script:

<$if parseDate(wfCurrentGet("lastEntryTs")) < dateCurrent(-7)$>
  <$wfSet("wfJumpName", "LateApproval")$>
  <$wfSet("wfJumpTargetStep",
    "NotifyAuthor@ApprovalPeriodExpired")$> 
  <$wfSet("wfJumpMessage", "The review period for content item
    <$eval(<$dDocTitle$>)$> has expired.")$>
  <$wfSet("wfJumpReturnStep", wfCurrentStep(0))$>
  <$wfSet("wfJumpEntryNotifyOff", "0")$>
<$endif$>

7.5.3.5 Jump Errors

Two responses are possible to a jump error:

  • An event script that causes an error in execution is treated as if it had never been evaluated. However, the default entry script that keeps track of the entry count and last entry is still evaluated.

  • A jump to an invalid step or a step in an inactive workflow results in an error, and the revision is treated as if it has completed the last step of the workflow.

7.6 Workflow and Script Templates

Workflow templates are a quick way to reuse workflows you have created. Each workflow template is an outline for a Basic, Criteria, or sub-workflow that is stored in the Workflow Admin tool. A workflow template is not tied to a security group, and it cannot include step event scripts. Use Script templates to store step event scripts.

The procedure used to create a template is similar to creating a workflow. This section provides an overview of the process. For more information, see Section 7.3.2 or Section 7.4.3.

This section contains the following topics:

Important:

When you use a workflow template, change the reviewers if they are different from those defined in the selected template.

7.6.1 Creating or Modifying a Workflow Template

To create or modify a workflow template:

  1. Display the Workflow Admin: Templates tab.

  2. To create a new template, click Add. To modify an existing template, select the template and click Edit.

  3. On the Add/Edit Template page, enter a template name in the Template Name field. You cannot change the Template Name after you create the template.

  4. Enter a detailed description in the Description field.

  5. Specify whether to permit the original author to edit the existing revision or create a new revision if the content item is rejected by checking the appropriate box.

  6. To Add a step, click Add.

  7. Enter an appropriate Name and Description for the step.

  8. Specify the authority level of the users for the step: Users can review the current revision, Users can review and edit (replace) the current revision or Users can review the current revision or create new revision.

  9. Click OK.

  10. Select the type of users for the step. You can define multiple types of user for a step.

  11. Click OK.

  12. Click the Exit Conditions tab.

  13. Specify how many reviewers must approve the revision before it passes to the next step.

  14. Specify additional exit conditions if needed.

  15. If the workflow requires conditional steps or special processing, click the Events tab and add the appropriate scripts.

  16. Click OK.

7.6.2 Creating a Script Template

Script templates are a quick way to reuse step event scripts. A script template is used as a starting point for creating event scripts. Each script template is a piece of Idoc Script stored in the Workflow Admin tool.

Important:

Script templates should use symbolic step names rather than explicit references.

To create a script template:

  1. In The Workflow Admin page, select Script Templates from the Options menu.

  2. Click Add.

  3. On the Add/Edit Script page, enter a script name in the Script Name field. The name cannot be changed after it is created.

  4. Enter a detailed description in the Description field.

7.6.2.1 Setting Up Jump Side Effects

  1. On the Jumps tab, click Add.

  2. Enter a jump name. The name cannot be changed after creating the jump.

  3. If the jump must specify a return point, select the Has Return Point check box and select a return point from the list.

  4. If users should not be notified when the jump is entered, select the Do not notify users on entry check box.

  5. If the content item is released before approval, select the Release document from edit state check box.

  6. Enter any custom side effects in the Custom Effects field.

  7. If users are notified when the jump is entered, click the Message tab and enter the notification message.

  8. Click OK.

7.6.2.2 Setting Up Script Template Conditional Statements

  1. Select a metadata field from the Field list.

  2. Select an operator from the Operator list.

  3. Select a value from the Value list.

  4. Click Add to add the conditional statement to the script.

7.6.2.3 Testing the Script

  1. Click the Test tab.

  2. Click Select.

  3. To narrow the content list, on the Content Item View page, select the Use Filter check box, click Define Filter, select the filter criteria, and click OK.

  4. Select a content item to test and click OK. If the selected content item is not currently in a workflow, it can be used to test the script but it is treated as if it were newly in the workflow.

  5. Click Select Workflow.

  6. On the Select Workflow Step page, select a workflow in the Workflows pane, select a step in the Steps pane, and click OK. Select a workflow step that is similar to the ones for which the script template is used.

  7. Click Load Item's Workflow State.

    If the selected content item is in a workflow, the companion file is loaded in the Input Data field.

  8. Click Test Script.

  9. The test results are displayed in the Results field.

    • The value of each parameter in the script is displayed.

    • If any Idoc script errors occur, they are displayed with the script containing the errors.

  10. To save the script template, click OK.

7.6.2.4 Changing a Script Template

To change an existing script template:

  1. On the Workflow Admin page, select Script Templates from the Options menu.

  2. On the Workflow Scripts page, select the script template to change.

  3. Click Edit.

  4. On the Add/Edit Script page, click Add, Edit, or Delete in the Jumps pane to change the jumps.

  5. Use the Field, Operator, Value fields and Add and Update buttons in the Script Clauses pane to change the conditional statements for the jumps.

  6. Use the Target Step list to change the target step for the jump.

  7. To modify the automatically generated script, click the Custom tab, select the Custom Script Expression check box, and edit the text.

    Caution:

    If you clear the Custom Script Expression check box, the expression reverts to its original definition and modifications are lost.

  8. Test the script before saving it. For more information, see Section 7.5.3.2.

  9. Click OK to save the changes.

7.6.2.5 Deleting a Script Template

To delete an existing script template:

  1. On the Workflow Admin page, select Script Templates from the Options menu.

  2. On the Workflow Scripts page, select the script template to delete.

  3. Click Delete.

  4. On the confirmation page, click Yes.

7.7 Workflow Scenarios

The following workflow scenario describe the planning process and the types of actions required to accomplish specific workflow tasks. It includes the following workflow examples:

7.7.1 Scenario 1: Criteria Workflow

Your Marketing department wants to have all marketing brochures approved by at least one of three graphic artists, the editor, and all of the marketing supervisors. The graphic artists and editor can edit the content, but the supervisors should not have editing privileges.

To set up the workflow for this example, you would:

  • Define a security group called Marketing, and ensure that the graphic artists and the editor have Write permission, and the marketing supervisors have Read permission to the security group.

  • Define a content type called MktBrochure.

  • Define a workflow called Marketing Brochures, with the security group set to Marketing and criteria set to Type = MktBrochure.

  • Define the first step, called Graphic Artist, as a Reviewer/Contributor step with approval required from at least 1 reviewer. Because the graphics department is very stable, you can assign the user logins of the three graphic artists to the step.

  • Define the second step, called Editor, as a Reviewer/Contributor step. Assign the editor's user login to the step.

  • Define the third step, called Marketing Team, as a Reviewer step with approval required from all reviewers. The management structure changes frequently, so set up an alias called MktTeam and assign it to this step.

  • All marketing brochures must be checked in to the Marketing security group with a Type of MktBrochure, so it is a good idea to instruct all possible contributors of marketing brochures about how to check them in.

  • For the approval process to work correctly, the MktTeam alias must be kept up-to-date.

7.7.2 Scenario 2: Tokens

After you created the Marketing Brochures workflow in Scenario 1, the Marketing department requested that all marketing brochures be returned to the original author for final review before they are released. The original author should not have editing privileges.

To set up the workflow for this example, you would:

  • Create a token called Author and define the user as dDocAuthor.

  • Define a fourth step in the workflow, called Original Author, as a Reviewer step. Assign the Author token to the step.

7.7.3 Scenario 3: Jump Based on Metadata

The Marketing Brochures workflow you created in Scenarios 1 and 3 is working smoothly, but now the Marketing department would like to automatically notify the various sales reps when a new brochure is released for one of their product lines.

To set up the workflow for this example, you would:

  • Define a required custom metadata field called Product, and create a list of the products.

  • Set up an alias for each product, and assign the appropriate sales reps to each alias. You can assign each user to multiple aliases.

  • Define a fifth step in the workflow, called Notify Sales, as a Reviewer step with approval required from zero (0) reviewers.

  • Define a sub-workflow for each product that contains one Reviewer step with approval required from zero (0) reviewers. Assign the corresponding product alias to the step.

  • Define an entry script in the Notify Sales step that jumps to the sub-workflow that matches the product.

  • For the notification process to work correctly, the product list and aliases must be kept up-to-date.

7.7.4 Scenario 4: Time-Dependent Jump

The Marketing department is having trouble getting marketing brochures approved quickly. They would like to change the Marketing Brochures workflow to automatically move content to the next step if it hasn't been approved or rejected by the graphics department, supervisors, or original author within 7 days. The editor is allowed a little more time. They get 10 days before the content goes to the next step.

To set up the workflow for this example, you would:

  • Define a script template called AutoApprove, with a target step that goes to the next step in the workflow if the last entry was 7 days ago.

  • Add an update jump to the Graphic Artist, Marketing Team, and Original Author steps. Use the AutoApprove script template to create the jump.

  • Add an update jump to the Editor step, using the AutoApprove script template. Edit the script so that the jump occurs at 10 days rather than 7 days.

7.8 Workflow Tips and Tricks

This section describes workflow tips and tricks:

In addition to this functionality, additional customizations are available through Consulting Services. For more information, see Section 7.8.6.

7.8.1 Requiring Step Authentication

It is sometimes necessary to re-authenticate a user for particular step of a workflow. For each workflow step that requires authentication before approval:

  1. Add the following line to the IntradocDir/config/config.cfg file:

    <workflow step name>:isRepromptLogin=true

    If multiple workflow steps require validation, add those steps on separate lines.

  2. Restart Content Server.

  3. Set up and enable the workflow, making sure to use the step name designated in the configuration entry for the step where validation is required.

When the workflow is initiated, the users at the workflow step designated with the isRepromptLogin configuration variable are prompted to login in before they can approve the content at the workflow step.

In the following example, validation is required at the steps named VIPApproval and CEOsignoff. The following entries are added to the config.cfg file:

VIPApproval:isRepromptLogin=true
CEOsignoff:isRepromptLogin=true

Content Server is restarted and a workflow is set up and enabled with steps named VIPApproval and CEOsignoff. Multiple users are assigned to the VIPApproval step, and only one user (the CEO of the company) is assigned to the CEOsignoff step.

Before the users at those steps can approve the workflow item, they must login again.

This functionality is available in Content Server 7.5 and later versions.

7.8.2 Setting Up Parallel Workflows

It is sometimes desirable to have two distinct groups of users able to review content items in workflow at the same time and to have a specified number of users from each group approve the content before it proceeds in the workflow.

When using Content Server, either all users or a specified number of users must approve the content before it continues. Usually the workflow does not differentiate between sources of approval. Consequently, all members of one group approve content while none of another group approve it, and the content would still advance through the workflow. The following code provides an example of how to add approval process discrimination.

This code allows step users to be set into groups. At each approval, the script checks for the group to which a user belongs. A user can belong to multiple groups; if the approving user is in a group, the counter for that group is incremented by one.

Extra exit conditions hold the content in the step until the extra conditions are met.

Add the following code in the entry portion of the step:

<$wfSet("set1", "0")$>
<$wfSet("set2", "0")$>
<$group1 = "user1, user2, user3,"$>
<$wfSet("group1", group1)$>
<$group2 = "user8, user9, user10,"$>
<$wfSet("group2", group2)$>

Add the following code in the update portion of the step:

<$if wfAction like "APPROVE"$>
<$if strIndexOf(wfGet("group1"), dUser) >=0$>
<$set1 = toInteger(wfGet("set1"))+1$>
<$wfSet("set1", set1)$>
<$endif$>
<$if strIndexOf(wfGet("group2"), dUser)>=0$>
<$set2 = toInteger(wfGet("set2"))+1$>
<$wfSet("set2", set2)$>
<$endif$>
<$endif$>

Add the following code in the extra exit conditions portion of the step (where n is the number of required approvers from group 1 and r is the number of required approvers from group 2):

toInteger(wfGet("set1")) >= n
toInteger(wfGet("set2")) >= r

By checking the approving user during each approve action, this workflow code increments the counter of the group to which the user belongs. The extra exit conditions hold the content item in the step until the minimum number of users in each group have approved it. If more than the minimum number of required approves for each group are executed, the approve actions are still logged but the content item does not proceed.

Reject actions are still absolute. A rejection from any named user still executes normal workflow reject behavior.

7.8.3 Adding Ad Hoc Step Users

You can add users to workflow steps without using metadata fields normally accessed by tokens. For example, a content item is traveling (and being edited) in workflow; each edit lists the person editing the content as the dDocAuthor. To send the item to the original author after the workflow cycle, a special token must be created:

<$wfAddUser(wfGet("originalContributor"), wfGet("type"))$>

Add the following code to the entry event of the first step in the workflow to restore the original author:

<$originalContributor=dDocAuthor$>
<$wfSet("originalContributor",originalContributor)$>
<$type="user"$> 
<$wfSet("type",type)$>

The event script uses wfSet() to put custom variables and values into the companion file at a point before the token call. The token then uses wfGet() to pull out those values and set the step user.

You can use this technique to obtain and store any standard or custom Idoc variable that holds valid user names or aliases. The Idoc variable can contain a comma-delimited list of user names or aliases. If user names are being stored, the <$type$> variable must be set to user (for example, <$type="user"$>. If alias names are being stored, the <$type$> variable must be set to alias (for example, <$type="alias"$>.

When placed in the entry event of a workflow step with the token set as the step user, the entry event code processes the information. It stores the user name (or alias) which is then called by the token and is set as a step user (or users, if a list was specified). Adding multiple or conditional code blocks and tokens (as shown previously) to your step entry events and step user definitions allows true ad hoc workflow routing.

7.8.4 Customizing Criteria Workflow E-mails

E-mails are triggered by criteria workflow at three points in the process:

  • On entry to a step.

  • On receipt of a reject reasons form.

  • On execution of the wfNotify Idoc script function.

It is possible to customize the e-mail message, the e-mail subject, and the template used for e-mails sent during criteria workflows. This section describes the processes for customizing the e-mail aspects of criteria workflows.

This section includes the following topics

7.8.4.1 Customizing E-mail Templates

The two most commonly used templates used to generate e-mail messages sent to recipients involved in a workflow are reviewer_mail.htm and reject_mail.htm. These are stored in IdcHomeDir/resources/core/templates.

You can modify these templates like any other template. E-mail template modification provides the greatest flexibility and opportunity for customizing workflow e-mails. Although this kind of modification is relatively straightforward, it still requires careful component development. Modifying the subject and the message in the e-mail is often the most important part of the message, and thus is often the most modified.

Custom workflow e-mail templates based on the standard templates can also be created. To call custom templates, add them as the optional third parameter to the wfNotify function, as in these examples:

<$wfNotify(userName, "user", templateName)$>
<$wfNotify(aliasName, "alias", templateName)$>

If an alternate template is not specified, the system default template is used.

For more information, see the discussion of wfNotify in Oracle Fusion Middleware Configuration Reference for Oracle WebCenter Content.

7.8.4.2 Customizing the Subject or Message Line

You can customize criteria workflow e-mail subject and message lines for your application.The e-mail subject line appears in the e-mail; the message line appears in the e-mail body with other information about the workflow e-mail (workflow name, step, and content item).

The message line defaults to one of two messages, depending on whether the step is notification-only (that is, if it has zero required reviewers).

You can customize subject lines and message lines in two ways:

  • You can modify the core string resource file according to standard component architecture.

  • For simple customizations, you can declare the wfMailSubject (for e-mail subjects) or wfMessage (for message lines) Idoc Script variable in a criteria workflow step event script or stored in the companion file.

7.8.4.2.1 Modifying Strings

The string definitions are as follows (variable 1 is the content item title and variable 2 is the name of the workflow step):

<@wwWfIsNotifyOnly=Workflow notification for content item '{1}' is in step '{2}'.@>

<@wwWfReadyForStep=Content item '{1}' is ready for workflow step '{2}'.@> 

<@wwWfRejected=Content item '{1}' has been rejected.@> 

You usually call these string definitions with the Idoc Script <$lc()$> localization function and you can alias them in a component resource file. For an example of e-mail subject line string includes, see the <@dynamichtml wf_approve_mail_subject@> include definition in the std_page.htm file.

7.8.4.2.2 Changing Idoc Variables

For simple e-mail or subject line changes, you can use Idoc Script rather than a component. You can place the wfMailSubject configuration variable or the wfMessage configuration variable in step event script. The value of these variables can also accept Idoc Script, as in this example:

<$wfMailSubject="My custom subject text for content with <$dDocTitle$> title"$>

No eval() function is required for the Idoc Script variables to evaluate.

If wfMailSubject or wfMessage is placed in the entry event of a workflow step, the e-mail messages triggered by content entering the step receives the customized subject or message line. These variables can also be declared before a wfNotify() function and the e-mail then generated by that function receives the customization.

7.8.5 Workflow Escalation

This example requires familiarity with tokens and coding.

Workflow escalation (that is, dynamically routing workflow content to different people than listed users) is a common workflow requirement. While this is easily accomplished with jumps and parsing of some criteria (for example, date, action, metadata) there is often some initial confusion or hesitation about where or to whom the content should go.

The issue is further complicated when the solution is to add a larger number of step users and to require only a subset of those users to approve the content before it can move on. This workflow still generates and sends out e-mails and appears in the workflow queue of non-approving users, users out of the office, and others who are there "just in case" some primary reviewer is not available.

7.8.5.1 Setting Up a Workflow Escalation

This solution incorporates two custom user metadata fields, a token, and workflow step entry and update event code.

  1. Create a user metadata field with the following elements:

    • name: OutOfOffice

    • type: text

    • option list: yes

    • option list type: select list validated

    • option list values: <blank>, false, and true

  2. Create another user metadata field with the following elements:

    • name: OutOfOfficeBackup

    • type: Long Text

    The OutOfOffice field is a flag that the user sets as TRUE when they are out of the office. To set this flag, select TRUE from the list and click Update to update the user profile.

    The OutOfOfficeBackup field contains the user name(s) of those users who can fill in as proxies for the out-of-office user. This field should optimally contain a single user name, formatted as shown in the User Admin applet.

    When the following workflow step event code finds that a listed user is "out of the office" it switches that user's name for the listed proxy (as designated by the value in the OutOfOfficeBackup field). The workflow step then restarts with only the users who had not yet approved the content and any designated proxies.

    A token pulls the list of users out of the companion file and sets them as step users. Special workflow messages are sent to designated proxies while the content was sitting in the update step event.

  3. Create a workflow Token

    • name: DynamicStepUsers

    • Token Code:

      <$if wfGet("dsu")$> 
        <$wfAddUser(wfGet("dsu"), "user")$> 
      <$else$>
        <$wfAddUser("sysadmin", "user")$> 
      <$endif$> 
        <$if wfGet("dsa")$> 
           <$wfAddUser(wfGet("dsa"), "alias")$>
      <$endif$> 
      

    The token pulls a value for the custom variable dsu and dsa out of the companion file. If no value is found for dsu then the sysadmin user is added as a precaution. The initial values for dsu and dsa are listed in the entry event of the step. If you want to assign users to the step(s), add the first contributor to the first step and the next step must include the first user plus the next user, user two.

  4. Paste the following code into the entry event of your workflow step. Comments are included through the entry code; remove the comments before inserting into your step:

    <$restartFlag=wfGet("restartStep")$>
    

    See if the cause is a restart for new backup users. If so, suppress notifications to old users and notify only new ones

    <$if restartFlag$>
    <$if toInteger(wfGet("restartStep"))>=1$>
      <$wfSet("wfJumpEntryNotifyOff", "1")$>
      <$oooUsers=wfGet("outOfOfficeUsers")$>
      <$if strIndexOf(oooUsers,",")>=1$>
    

    Check for multiple out of office users

    <$wfMessage=eval("The Following Users are out of the office: <$oooUsers$>
      \nYou are the designated backup for one of them.\n
      The content item <$dDocName$> is in the workflow step <$dwfStepName$> awaiting your   review")$>
    <$else$>
      <$wfMessage=eval("The Following User is out of the office: <$oooUsers$>
      \nYou are the designated backup for this user.\n
      The content item <$dDocName$> is in the workflow step <$dwfStepName$> awaiting your   review")$>
    <$endif$>
    <$rsMakeFromString("ooou",oooUsers)$>
    <$loop ooou$>
      <$userBackupName=row&"_Bkup"$>
      <$wfNotify(wfGet(userBackupName),"user")$>
    <$endloop$>
    <$wfSet("restartStep","0")$>
    <$endif$>
        <$else$>
    <$wfSet("restartStep","0")$>
      <$endif$>
    

    Set your step users here. Multiple users must be comma-delimited, user names must be in quotes, metadata field references are unquoted. This example proceeds, using user names rather than aliases. Slight code re-working is required if using aliases.

    <$dynamicStepUsers= <LIST USER NAMES IN QUOTES HERE>$>
    
    <$if strIndexOf(dynamicStepUsers,",")>=1$>
    

    If there are multiple users specified verify if any of the MULTIPLE users are out of the office

    <$rsMakeFromString("multiDynamicUsers",dynamicStepUsers)$>
    <$loop multiDynamicUsers$>
      <$if strEquals(getValueForSpecifiedUser(row,"uOutOfOffice"),"true")$>
    

    If user is out of office, get their backup

    <$backup=getValueForSpecifiedUser(row,"uOutOfOfficeBackup")$>
    

    Replace out-of-office user in users list with their backup

    <$dynamicStepUsers=strReplace(dynamicStepUsers,row,backup)$>
      <$endif$>
      <$endloop$>
       <$else$>
    

    Verify if the SINGLE user is out of the office

    <$if strEquals(getValueForSpecifiedUser(dynamicStepUsers,"uOutOfOffice"),"true")$>
    

    If user is out of office, get their backup

    <$dynamicStepUsers=getValueForSpecifiedUser(dynamicStepUsers,"uOutOfOfficeBackup")$>
      <$endif$>
    <$endif$>
    <$wfSet("dsu",dynamicStepUsers)$>
    

    Set the dsu variable into the companion file with listed and backup users

  5. Paste the following code into the update event of your workflow step, removing comment lines before doing so:

    <$remainingUsers=wfGet("wfUserQueue")$>
    

    Get users who have yet to approve

    <$rsMakeFromString("ru", remainingUsers)$>
    <$loop ru$>
    <$if strEquals(getValueForSpecifiedUser(row,"uOutOfOffice"),"true")$>
    

    Check the remaining users to see if they are out of the office

    <$if getBackup$>
    

    Create list of users requiring backup substitutes

    <$getBackup=row &","&getBackup$>
    <$else$>
      <$getBackup=row$>
    <$endif$>
    <$endif$>
    <$endloop$>
    <$if getBackup or strLength(getBackup)>0 $>
    

    If a user is listed as out of office then rewrite the user list and restart the step

    <$wfSet("outOfOfficeUsers",getBackup)$>
    <$rsMakeFromString("needBkup", getBackup)$>
    <$loop needBkup$>
    <$bkupUser=getValueForSpecifiedUser(row,"uOutOfOfficeBackup")$>
    <$newRemainingUsersList=strReplace(remainingUsers,row,bkupUser)$>
    <$wfSet(row&"_Bkup",bkupUser)$>
    <$endloop$>
    <$wfSet("dsu",newRemainingUsersList)$>
    <$getBackup=""$>
      
    <$wfSet("wfJumpTargetStep", wfCurrentStep(0))$>
    <$wfSet("restartStep","1")$>                             
    <$endif$>
    

7.8.6 Other Customizations

Many workflow customizations are available through Consulting Services. This section briefly describes two of those customizations. Please consider engaging Oracle Consulting Services for a thorough evaluation of the impact associated with the replication of workflow examples.

The following customizations are discussed in this section:

7.8.6.1 Setting Approval by Non-Reviewers

It is sometimes necessary to have a person approve content in a workflow step even if that individual is not part of the actual workflow. For example, if you want an outside opinion on a document in a particular stage in a workflow or if you want to designate a substitute reviewer because another reviewer is out of the office. The individual can approve content but they do not get normal workflow notifications and do not see the content items in their workflow queues.

Users with designated roles or who are members of designated aliases can approve content on this basis. These designated users see a Bypass Approve link in the workflow actions box for each item in a workflow to which they have normal security access. Performing a Bypass Approve approves the content item in the step in which it currently resides. Defined step exit conditions are still evaluated and still apply. The approval is logged in the Workflow History database table and in the WorkflowActionHistory ResultSet of the companion file.

A designated approver is not a regular workflow step approver and thus does not receive automatic workflow notifications. Access to a content item in a workflow where the approver wants to perform a Bypass Approve action must be intentional. The designated approver must access the Active Workflows menu, then select the workflow name and select an action.

The designated approver component aliases core resources. If other components are running or are planned, this must be taken into account. In some cases, you can combine component resources to include all required functionality or you can rename and re-reference them to keep all components working correctly (but separately).

7.8.6.1.1 Scenarios

For the following scenarios, assume that User A has a role or alias that grants designated approver status and that a sample workflow named MyWF has two steps.

  • Scenario 1: User A is listed as an approver for step 1 in MyWF but not in step 2. Therefore, no Bypass Approve link appears for Step 1. User A received default workflow action capabilities and notifications. The Bypass Approve link for step 2 appears under the Workflow Actions menu if User A accesses the Content in workflow 'MyWF' page when the content item is in step 2.

  • Scenario 2: User A is not listed as an approver in MyWF. The Bypass Approve link appears in the action menu on the Content in workflow 'MyWF' page for all steps and for all content to which User A has at least Read permission in its Security group.

  • Scenario 3: User A is not listed as an approver for Step 1 in MyWF. Step 1 requires two approvals from reviewers before it moves to step 2. The Bypass Approve link appears for User A. Click Bypass Approve to register an approval and fulfill one of two required approvals for the step to continue in the workflow.

7.8.6.2 Automatic Replication of Workflow Items

Content items are often processed (in one form or another) before they are 'released'. A released content item is indexed and can then be included in search results, archives, and in other processes and applications.

It is sometimes useful to release a content item before its completion in the workflow. For example, a content item must be in a released state to be replicated (and perhaps later used in disaster recovery). Items not released (such as items in workflows) are not used by the replicator.

It is possible to designate workflow items as released while still in workflow. Normal workflow actions, such as updating, checking out, and checking in are still available. However, these items are indexed and appear in search results, can be used in replication and archiving, and in any other processes or applications.

Important:

There are several elements to consider before replicating workflow items. This section describes the process but does not go into detail; contact Consulting Services before setting up replication of workflow items.

7.8.6.2.1 Potential Conflicts

There are several points to be aware of before setting up automatic replication:

  • Loss of data integrity: A premature release of content, whether intentional or otherwise, can have unforeseen effects on business process management, content accessibility, and information integrity. Potential ramifications must be thoroughly considered before the release of items still in workflow is considered.

  • Non-capture of workflow information: Workflows are a combination of process and content. While it is possible to release content and make it available for replication and other processes, it is not possible (without customization and assistance from Consulting Services) to capture and replicate workflow state information.

    If content in a workflow on a source instance is replicated and released on a target instance without passing through a workflow on that instance, the recovery process involves manual effort to re-set the content's workflow state.

    In most cases, cloning of workflow information is not necessary because recovery to a prior workflow state is required only during true disaster recovery. In all other cases, content items replicate as normal after exiting a workflow and supersede versions or revisions replicated during workflow.

  • Imported content items do not enter workflow: Content items replicated while in a workflow on a source instance do not enter a workflow on the target instance without additional customization and assistance from Consulting Services. Replicated content items are checked in to the target instance and released.

  • Restoration of replicated workflow items requires manual intervention: You can capture some workflow information as metadata for use in a manual restoration of the workflow. Only a check-in action triggers a content item's entry into workflow. To restore an item back into a workflow requires that you create a revision.

    To recover the content items on the target to a state as close as possible to their previous state on the source, a discrepancy between the number of revisions on the source and the target instances is intentionally and unavoidably introduced.

7.8.6.2.2 Scenarios

For content item 1, not released while in workflow, the following is true:

  • The content item moves through workflow in a non-released state.

  • The content item is not a candidate for replication while in workflow.

  • The content item is available only to named workflow step reviewers and administrators.

  • When the content item completes the workflow, it is released, indexed, and is now a candidate for replication.

For content item 2, released while in workflow, the following is true:

  • The content item moves through workflow and is released as specified. After an item is released, it cannot be 'unreleased'. New revisions of a content item created during workflow are not released unless specified.

  • Content items released while in workflow display in search results and can be viewed by users with the appropriate security access.

  • Users cannot edit, check out, check in, or update a released item that is in workflow unless they are designated users for the step in which the item is located and that step allows the attempted action.

  • A content item released while in workflow is a candidate for automatic replication. The Replicator treats the item as if it is not in workflow.

  • Content items completing workflow are replicated in the normal fashion and supersede any pre-existing content item versions replicated during workflow.

For information about implications of the release of content items in workflow for replication or other purposes, contact Consulting Services.

7.8.7 Triggering Criteria Workflows from Folders

It is sometimes necessary for documents in a particular folder to go through a criteria workflow. However, when you create a criteria workflow based on a folder, the criteria option of folder is not listed in the field list. The field list in criteria workflows only lists fields with a type of text or long text. Because Folder (xCollectionID) is an integer field, it is not an option.

Although you cannot select the folder field on the Edit Criteria form, you can define it as a criterion in Events. In the Entry Event of the first step, you can set up criteria to check for the appropriate folder number (xCollectionID). If it does not fulfill the criteria, the item can exit from the workflow.

The following general steps detail how to set up such a workflow:

  1. Start a new criteria workflow and choose the Security Group that the workflow uses.

  2. In the Criteria Definition section, define global criteria to monitor all of the documents that enter the system. For example:

    Field: ContentID
    Operator: Matches
    Value: *
    

    To monitor only items coming in through a specific folder, set an extra metadata field that specifies a folder number.

    If multiple workflows are in place, you can filter all content through this workflow and jump to sub-workflows through multiple criteria settings in the first step of this workflow.

  3. Add the first step to the workflow.

  4. In the Events tab, click Edit from the Entry Event.

  5. On the Jumps tab, click Add.

  6. Give the jump a meaningful name (for example, Folder Criteria) and click OK.

  7. For the jump criteria, enter the following:

    Field: Folder
    Operator: Not Equals
    Value: Folder ID on which the workflow is based
    

    When done, click Add.

  8. For the Target Step, select Exit to Parent Step and change both of the 0 parameters to 10 (for example, @wfExit(10,10). Documents not in the folder are forced out of the workflow.

  9. Click OK on the Entry Event and click OK on the Add New Step dialog.

  10. Add the necessary jumps, steps, and events for the rest of the workflow and enable it.

7.8.8 Searching Within a Workflow Step

When executing the GET_SEARCH_RESULTS service within a workflow step, you can experience data corruption because the workflow's data binder is being used by the service.

A solution for this is to temporarily set the security group value into a temporary variable. Then clear the current security group value, make the call for the search results, then reset the security group back again.

7.8.9 Suppressing Workflow Notifications

When a workflow step requires multiple approvers, a user who has approved the document can be re-notified during a timed workflow update cycle. To prevent additional notifications, use the wfSetIsNotifyingUsers workflow function. Used in a workflow step in the script section of the workflow, it sets an internal flag to determine if workflow notifications are sent out during the current document action (check in, approve, update, and so on). The suppression is applied to both e-mail and updates to the workflow in the queue.

When used in combination with wfIsFinishedDocConversion, this function can suppress notification until conversion is finished. It does not prevent documents from advancing out of the auto-contributor step but it does stop updates of the workflow in queue and notification e-mails.

These notifications are not lost. If the wfSetIsNotifyingUsers function is not used in a future workflow event to suppress notifications (updates to workflow in queue and workflow mail) then all users participating in the current step are notified.

You can use the following additional functions in the script section:

  • wfIsFinishedDocConversion, which returns a result indicating if the document is not in GENWWW after the current document action ends.

  • wfIsNotifyingUsers, which returns a result indicating if the workflow is currently suppressing all workflow notification for this particular workflow event.

For information about using these functions, see Oracle Fusion Middleware Developing with Oracle WebCenter Content.