9 Approving and Publishing Content
About Approval, Publishing, Revision Tracking, and Workflow
The goal of using WebCenter Sites is to publish content to a website where site visitors can read and interact with it. Before an asset can be published, it has to be approved for publishing. When you approve an asset, you acknowledge that the content of the asset is ready to be published. To help keep track of which assets are ready for approval, your administrator can assign them to a workflow. A workflow routes assets through a series of editorial tasks by assigning the tasks to the appropriate users at the appropriate times. For example, an asset whose workflow status is Ready to Edit would be assigned to an editor while an asset whose workflow status is Ready to Approve, has been reviewed and is ready to be approved for publishing.
To further assist is the process of moving your assets from the management system to the delivery system, WebCenter Sites provides the revision tracking feature. Revision tracking is an optional feature which must be enabled by your WebCenter Sites administrator for the asset types on your site. Revision tracking enables you to track and control the changes made to your assets.
For information about approval, publishing, revision tracking, and workflow, see these topics:
About the Approval Process
Asset approval can be either manual or automatic. You can manually approve content assets and page assets by clicking the Approve icon in an asset's toolbar. You can also manually approve these types of assets directly from a search results list. Form View enables you to approve the primary asset (asset with which you are working). Web View enables you to approve the primary asset and all assets displayed in the primary asset's web page view. If any of the assets you are approving have dependent assets that need approval, WebCenter Sites displays a list of dependent assets which you can then approve in bulk. Additionally, you can manually approve site navigations and navigation pages (Page assets) from the Site Tree.
Asset approval can also be automated. For example, your administrator can configure a workflow process in such a way that its final step automatically approves assets in the workflow for publishing to one or more destinations.
Dependencies
Dependencies are conditions that determine whether an asset can be published. An asset dependency exists when the asset is associated with other assets. For example, a Product asset has an association with a Datasheet asset. The Datasheet asset has an association with three Image assets. Two of these images have associations with Article assets. This tree hierarchy forms a set of parent/child dependencies among all these assets.
The approval status of an asset indicates whether the asset can be safely published; that is, whether any dependency conflicts exist. An asset's approval status is determined by its dependency relationships, which include the approval status of all assets associated with a particular asset, and the dependency relationships of those associated assets.
Note:
Site navigations do not have any dependent assets during the approval process.
For more information about how WebCenter Sites calculates asset dependencies during approval and publishing, see Understanding Publishing in Administering Oracle WebCenter Sites.
Approval States
Because of the dependencies between assets, and the nature of the dependencies, approving an asset involves the concept of approval states. For example, Held is an approval state an asset enters when the asset is approved for publishing, but its dependent assets are not. In such case, the asset is then held from publishing until its dependents are approved.
Table 9-1lists all the possible approval states of an asset and what each state means.
Table 9-1 Approval States
State | Meaning |
---|---|
Approved |
(Informational) The asset is ready to be published to this destination, unless the asset, or one of its dependent assets (in Exact dependencies), is edited. |
Held |
(Action required) The asset will be held until the dependents are approved. |
Needs Approval |
(Action required) The asset requires approval. Click Approve to initiate the approval process. |
If an asset enters an approval state that prevents publication, WebCenter Sites displays a list of dependent assets that require approval. When all assets are approved, they can be published.
To learn more about the approval and publishing mechanisms employed by WebCenter Sites, see Understanding Publishing in Administering Oracle WebCenter Sites.
About the Publishing Feature in the Contributor Interface
The Publishing feature in the Contributor interface is part of the WebCenter Sites publishing system and gives WebCenter Sites users, who are assigned the Publisher role, the means to migrate individual assets from the management system to the delivery system. WebCenter Sites also provides an approval system that determines which assets can be published. An asset must be approved before it is published. For more information about the WebCenter Sites publishing system, see Understanding Publishing in Administering Oracle WebCenter Sites. For more information about publishing assets from the Contributor interface, see Using the Publishing Feature in the Contributor Interface.
About Revision Tracking
When revision tracking is enabled, you control whether other users can edit or delete an asset by checking it out and back in. You can either check assets out manually, or you can let WebCenter Sites handle the check out process automatically. If you allow WebCenter Sites to automatically check assets out to you, you still have to manually check assets back in when you are done working with them.
Checkout and Checkin
When revision tracking is enabled, the following commands control access to assets:
-
Check out. Only one user can check out an asset at any given time. If other users try to check the asset out or modify it, WebCenter Sites informs them that the asset is locked by someone else.
If an asset is assigned to you in a workflow, and you have checked out the asset, then you cannot finish your assignment until you check the asset back in.
If you check out an asset, it cannot be approved for publishing until you check it back in.
-
Undo Checkout. If you check out an asset and then decide that you do not want to save the changes you have made to it, cancel or undo the checkout. In this case, the asset is simply unlocked, changes are reverted back to the most current version of the asset, and no new version is saved.
-
Check in. You check in assets that you have checked out. After the asset is checked in, others can work with it, and if the asset is assigned to you in a workflow, you can finish your assignment.
When you check in an asset that you have checked out, a record is made of the checkin, and a copy of the last saved version of the asset is preserved as a new version (the number of versions kept is set by the administrator).
Another option is to check in the asset so that you have an archived version but to keep it checked out. This option enables you to create a version but keeps the asset checked out to you.
If you edit an asset that is not checked out to you, WebCenter Sites checks it out to you automatically. When you save the edited asset, WebCenter Sites does not check the asset back in for you. Therefore, you still have to manually check the new version of the asset back in after you save the changes you have made to it. Similarly, if you do not want to save the changes you made to an asset that is checked out to you, you have to manually undo the checkout.
If you delete an asset that is not checked out to you, WebCenter Sites checks it out to you for deletion. This ensures that no other users can work with the asset as you are deleting it from WebCenter Sites. A deleted asset is no longer checked out to you because it no longer exists in the system.
Releasing Locked Assets
If you edit an asset when revision tracking is enabled, the asset is automatically checked out to you. Because of this, you may accidentally check out an asset while you work in the WebCenter Sites interface. When an asset is checked out to you, the asset is locked and prevents other users from working with it. To ensure you are not preventing other people from working with assets you have inadvertently checked out, review the assets checked out to you by viewing the Checkouts section of your dashboard (located in the Home tab) and check in (or, if you do not want to commit your changes to the database, undo the checkout of) any assets that you do not have to lock.
Functions That Automatically Checkout an Asset to You
Table 9-2 describes asset management functions that check assets out automatically:
Table 9-2 Functions that Automatically Checkout an Asset to You
Function | Effect on Revision Control |
---|---|
Create |
As soon as you create an asset, the asset is checked out to you. |
Edit |
Checks out the asset and prohibits other users from editing or deleting it. |
Copy |
Creates a new copy of the asset. The source asset cannot be checked out during the copy operation. As soon as you create a copy of an asset, the copy is automatically checked out to you. |
Rollback and Revision History
When you check in an asset that you have checked out, WebCenter Sites stores a new version of the asset and adds it to a list of previous versions. You can later restore the asset to one of those previous versions and you can examine the asset's revision history.
Note:
The volume of revisions to be saved for a given asset may be limited (depending on your administrator's configurations). Therefore, earlier versions of the asset could be overwritten. In this case, the overwritten version is not shown in the asset's revision history. An asset cannot be rolled back to a version that has been overwritten.
-
Rollback means restoring the asset to a previous version. When you have an asset checked out, you can roll it back to any previous version, (provided it was not overwritten and not the first, SYSTEM, version). Rollback restores the contents of the asset, but does not reset its status (created, edited, and so on) as of the previous version, nor does it affect workflow status. If the asset is part of a workflow, anyone who has the appropriate permissions can restore it to a previous version.
-
Revision History. You or any user can list and examine the revision history of an asset. The revision history also shows who, if anyone, currently has the asset checked out. You can also see comments entered by the user who checked the asset in at the time, if the user chose to enter a comment, by looking at the Comments section of the revision history table.
About Workflow
The following topics describe basic workflow concepts and terminology.
Note:
In addition to the functionality described in the topics listed above, WebCenter Sites provides the following workflow functionality through the Admin interface:
-
Workflow groups allow you to manage a defined set of assets in a coordinated manner that allows those assets to reach the end of the workflow process together, before publishing.
-
Workflow reports allow you to track the progression of assets and user assignments in workflow.
Workflow and Assets
Depending on how your site is configured, assets can be assigned to a workflow either automatically (for example, when you create an asset) or manually. The workflow system lets WebCenter Sites direct and track the assignment of assets to users and specifies what users can do with those assets through permissions.
The flow of the editorial tasks performed on the asset, and who is authorized to perform those tasks at each point in the workflow is defined by a workflow process. The workflow administrator can define as many workflow processes per asset type as needed.
Note:
During workflow, the asset is not electronically transferred from one person to the next. What is transferred is permissions to the asset. The asset itself remains in its original location in the database throughout the workflow process and throughout its existence in WebCenter Sites.
States and Steps
A workflow process defines a series of states. A state is a point in the workflow process that represents the status of the asset at that point, for example, Ready to Edit or Ready for Approval.
States are linked together in a specific order by steps. A step is the movement of the asset between states. Because creating workflow steps links workflow states in a specific order, creating steps in a workflow process is what organizes the process. In each step, the asset goes from a start (from) state to an end (to) state. When creating the workflow process, the administrator defines the states and links them through the appropriate steps.
Steps and states have names; for example, in the FirstSite II sample site, Send for Approval is a step originating from the Ready to Edit state and resulting in the Ready for Approval state. An asset can move from one state to another through multiple steps. For example, an asset that is ready for approval can be rejected because of factual errors or stylistic problems, each type of rejection having its own step.
Assets are assigned to users by roles. As an asset progresses through the workflow, each step assigns it to users holding roles authorized to work on the asset in the next state. For each step, at least one role is authorized to complete work on an asset and allow it to continue moving through the workflow. In certain cases, a user holding the appropriate role can choose between steps; for example, a user holding the Approver role can either approve or reject an asset assigned to him/her for approval.
When you log in to WebCenter Sites, the Assignments widget on your dashboard (Home tab) provides a summary of your present workload, from which you can access the assets assigned to you. When your work on the asset is complete, you use the Finish Assignment function to start the next step in the workflow; the workflow process then moves the asset to the next state and assigns the asset to the appropriate users. Note that a step can be conditional; that is, certain users or all users can be prevented from taking a step until some condition is met.
Users, Roles, and Participants
A user in WebCenter Sites is a person who is assigned a WebCenter Sites user name which he/she uses to identify him/herself and to log in to WebCenter Sites. What a user can or cannot do is determined by the role (or roles) assigned to that user by the administrator.
A role describes and determines the functions of a user in a CM site by granting that user permissions to perform specific functions; in the context of workflow, these permissions are called function privileges.
The workflow process grants roles (not individual users) the appropriate function privileges. The function privileges are enforced only when an asset has been assigned to a workflow. Function privileges depend not only on the user's role, but also on the state of the asset and whether the asset has been assigned to the user.
Note:
Because function privileges are granted to users through their roles, they function independently of the access permissions assigned by the administrator at the user level.
For example, a user might not normally have the permission to edit Content assets, but he/she can have the function privilege to do so if he/she has the Editor role, is participating in a workflow process for Content assets, and the asset he/she wants to edit is in the appropriate workflow state.
Each role required by a particular workflow state in a workflow process is a participating role. Participating roles are chosen for each state in a workflow process by the administrator. Each user whose assigned roles match those required by that workflow state is therefore a participant for that state in the workflow process and is authorized to take the workflow step leading from that state to the next state.
Unless the administrator decides otherwise, assets placed in workflow are assigned to all available participants for a given role. However, depending on how your administrator configured a given workflow step, you may have the option of limiting which users can work with a particular asset by choosing the assignees from among the participants available in each participating role.
An assignee is a workflow participant chosen to work on a specific assignment. Assignees are set when an asset is assigned to a workflow, but you may have the option of choosing different assignees when the asset is in a workflow process. How assignees are chosen for a workflow process is determined by the configurations your administrator made to the steps in the workflow process. Workflow steps can be configured to allow users assigned specific roles to choose assignees. However, workflow steps can also be configured to automatically assign an asset to all users with a specified role or to assign an asset to only the user who created it.
When assignees are set for a given asset in the workflow, only the chosen assignees see the asset in their assignment lists, and only they can complete the assignment before the workflow process changes the state of the asset.
Workflow Assignments
An assignment is an asset on which a chosen participant (an assignee) is (or is supposed to be) working. An asset is on the participant's assignment list as soon as the asset enters a state for which the participant has a role to fulfill.
A typical workflow design generates an e-mail notification when you are given a workflow assignment. You can see an updated list of your assignments at any time in the Assignments section of your dashboard (located on the Home tab).
Assignment Duration
Each workflow state has an associated estimated time of completion (deadline) for an assignment. If the administrator has granted you the appropriate permission, you can override the default estimate for the next assignment.
As the assignment deadline nears, associated assignment actions in the form of e-mail notifications can be triggered as timed events relative to the estimated time to completion. For example:
-
You receive a reminder the day before your assignment is due.
-
You and the workflow initiator receive a warning the day the assignment is due.
-
The initiator receives notification the day after the due date that the assignment has not been completed.
Voting Your Assignments
If you participate in workflow, you have a vote. Voting means taking a workflow step that moves the asset from its current state to the next, after you have completed the task required by the current workflow state (such as editing an article) and committed the changes to the WebCenter Sites database (saved the asset), if applicable. You cast your vote by either using the Finish Assignment function (available in the Assignments widget on your dashboard) or by viewing the status of an asset and finishing your assignment using the Workflow commands drop-down list (accessible by selecting View and then selecting Status in the menu bar when working with the asset). If multiple participants with a given role has the assignment, either one, or all of them must vote before the asset moves to the next state, depending on how the workflow was set up by the administrator.
Depending on your role in the workflow process, when you vote to finish the assignment you may be given a choice of steps to take; for example, if you are an approver and your current assignment is to either approve an asset for publishing or reject it, when you finish your assignment you can either choose a step that approves the asset for publishing, or choose a step that rejects it due to factual error, depending on your choice. When you vote, the asset moves to the next workflow state unless the step you chose is in disagreement with the step chosen by other assignees with the same role as you.
If, for some reason, you are unable to complete your assignment, you can abstain from voting, if yours is not the last (or only) vote for that particular role, or step, or both. When you abstain, you still have the assignment, but the asset can continue through workflow. If you change your mind, you can reverse your abstention by voting again, if the asset has not moved to the next state.
Delegating Your Assignments
Another way of handling an assignment is to delegate it to another participant holding the same role as you, assuming the asset you are delegating is not assigned to that person for the current workflow state.
Your function privileges (set by the administrator) determine whether you can delegate your assignments. Also, the administrator can delegate assignments on your and other assignees' behalf, if necessary.
Delegating an assignment can trigger associated delegate actions in the form of e-mail notifications. For example:
-
The recipient of the new assignment is notified.
-
The workflow administrator is notified of the assignment delegation.
Deadlocks
An asset moves from one state to the next when assignees cast their votes (that is, take a step) for a given workflow state. When defining the workflow process, the administrator decides whether each step is all-voting, that is, whether all assignees must vote (take the step) for the asset to move to the next state. By default, steps are not all-voting, which means that the first assignee to vote in a given workflow state determines the flow of the asset, and the assignments for the remaining assignees for that workflow state are cancelled. If the administrator set the step to be all-voting, the asset is held in its current workflow state until all assignees have voted, at which time the asset moves to the next state.
If a choice of steps exists and each step is all-voting, the potential for a deadlock exists. A deadlock occurs when all of the assignees must vote, and the voting is not unanimous on which step to take. A workflow process typically includes a deadlock action to generate e-mail notifications to all assignees, showing the vote tally and advising all assignees to vote again in favor of the majority. Deadlocks cause additional work for all the users involved, and should be avoided whenever possible. They should also be resolved as quickly as possible so that the flow of work is not hindered.
Sample Workflow
The FirstSite II sample site includes six sample workflow processes which guide assets of different types from creation to approval for publishing. The sample workflows are simple, transitioning through three states by using five possible steps, but they serve to illustrate how a workflow process works. This section is based on the FSII: Approval for Content sample workflow process included in the FirstSite II sample site.
The FSII: Approval for Content sample workflow process has the following roles participating: author, editor, approver, and administrator. Each role has only a single participant (your organization most likely has more complex processes, with several users participating in each role). A participant from any of the roles can create a Content asset, which automatically assigns it to the FSII: Approval for Content workflow. By creating the asset, workflow is initiated. The asset then moves from author to editor to approver. The approver can either approve or reject the asset. If the approver rejects the asset, it goes back to the editor. The administrator can perform the functions of author, editor, and approver at any point in the workflow. The administrator can also return an approved asset back to the editor for additional changes.
Sample Workflow States and Steps
The FirstSite II sample site includes a sample workflow process called FSII: Approval for Content. The flow of the process is shown in Figure 9-2.
The steps and states from this workflow process are described in Table 9-3:
Table 9-3 States and Steps
Asset in State... | Step | Description | Asset Moves to State... |
---|---|---|---|
none |
Create |
A user with the ContentAuthor role creates a Content asset, which automatically assigns it to the FSII: Approval for Content workflow. |
Ready to Edit |
Ready to Edit |
Send for Approval |
A user with the ContentEditor role receives an e-mail notification of the assignment. The editor revises the asset to complete the assignment. |
Ready for Approval |
Ready for Approval |
Reject |
A user with the Approver role receives an e-mail notification of the assignment. The approver completes the assignment by rejecting the asset because of factual errors. The rejection triggers a notice to the editor, who must make some corrections and resubmit the asset for approval. |
Ready to Edit |
Ready for Approval |
Approve and Lock |
The approver completes the assignments by approving the asset. The asset is flagged in the WebCenter Sites database as ready to publish for selected destinations. |
Approved and Locked |
Approved and Locked |
Return for Edit |
The workflow administrator (holding the Workflow Admin role) reviews the asset and determines if the content should be updated with additional information. The workflow administrator then uses votes to return the asset to the editor for revision. |
Ready to Edit |
Sample Workflow Scenario
This section describes the typical flow of a Content asset through the FSII: Approval for Content workflow process.
1. The author creates the asset and writes the content
The process starts when Conrad the author creates the Content asset. Since the Content asset type in the FirstSite II sample site is configured to automatically place each new Content asset in workflow, Conrad's asset is automatically placed into the FSII: Approval for Content workflow process. Conrad writes the content and saves the Content asset.
When Conrad saves the asset, the workflow process automatically changes the state of the asset to Ready to Edit, assigns it to Connie the editor, and sends Connie an e-mail notice about the new assignment.
2. The editor edits the asset and sends it for approval
Connie the editor logs in, checks her assignment list, and opens the Content asset for editing. She reads the content and fixes some punctuation. When done, Connie saves her changes and then votes to send the asset on for approval.
The workflow process changes the state of the asset to Ready for Approval, assigns it to Napoleon the approver, and sends Napoleon an e-mail notice about his new assignment.
3. The approver approves the asset
Napoleon the approver is logged in, so when he receives his e-mail, he accesses the Assignments widget on your dashboard to view his assignment list. Napoleon opens the newly assigned Content asset and examines it. It looks fine, so he can vote to either approve or reject the asset for this workflow process. The workflow process presents both options to him.
Note:
If two or more users with the same role have the same assignment in a given workflow state, the first vote cast determines the next state for the asset.
For example, if the FSII: Approval for Content workflow process included two approver users who both had a vote when approving the asset for publishing, a rejection by either of them would cancel the assignment of the other person and return the asset to the editor.
Your administrator might set up a workflow in which a disagreement like this causes a deadlock (see Deadlocks) that has to be resolved before the asset is returned to the previous state or moved to the next one.
Since Napolean voted to approve the asset, the workflow process changes the state of the asset to Approved and Locked, and flags it in the database as ready to publish. The asset can either be published immediately from the Contributor interface or during the next publishing session (scheduled by your administrator).
4. The workflow administrator returns to the editor
When new information becomes available, it has to be added to the asset. When that happens, the workflow administrator can vote in the workflow process to return the asset to Connie for review and updating.
The workflow process automatically changes the state of the asset to Ready to Edit, assigns it to Connie the editor, and sends Connie an e-mail notice about the new assignment.
When Connie finishes her assignment, the updated asset must be re-approved before it can be re-published to the website.
Performing Approval Tasks
This section provides information about the approval tasks you can perform on an asset.
For information about performing approval tasks, see these topics:
Approving an Asset for Publishing
The following procedure describes how to manually approve content assets and Page assets for publishing. Before approving an asset for publishing, you should preview it first.
To approve an asset for publishing:
Approving a Site Navigation for Publishing
From the Site Tree you can approve site navigations, the Pages placed under a site navigation, Device Groups, and Device assets. The approval of Site Navigation assets is not dependent on any other assets. However, for your site to be ready for publishing, you have to approve all Device Groups on your WebCenter Sites system, the Page assets placed under the site navigation, and the content assets associated with those Pages. If you are approving a site navigation for publishing to a management system, you must also approve all Device assets associated with that site navigation.
Note:
For more information about site navigations, Device Groups, and Device assets, see Working with Mobile Device Content.
To approve a site navigation for publishing:
Removing Assets from the Publishing Queue
If you decide not to publish an approved asset, you can unapprove the asset. When you unapprove, WebCenter Sites removes the asset from the publishing queue (for the given destination) and changes its status to Needs Approval. If the unapproved asset is a child (referenced asset) of one or more assets in the publishing queue, WebCenter Sites removes the parent (referring) assets from the publishing queue for the destination and changes their approval states to Held.
To remove an asset from the publishing queue:
Using the Publishing Feature in the Contributor Interface
Primarily, it is the WebCenter Sites administrator’s job to publish assets from the management system to the delivery system by running either a bulk publish on all approved assets on the system or by scheduling a reoccurring publish event. If you are assigned the Publisher role, you can work with the Publishing feature in the Contributor interface. The Contributor interface’s publishing feature is for quick, on-demand, publishes of one or more assets during a period where no other publishes are scheduled to run. You can publish an individual asset directly from its Approval page or publish multiple assets from the search results list.
The following topics provide information about using the publishing feature in the Contributor interface:
Publishing an Approved Asset
If you are assigned the Publisher role, you can trigger an on demand publish on an asset after you approve it. This enables your changes to immediately hit the website, instead of having to wait for a scheduled publish or for your administrator to publish it.
For detailed information about WebCenter Sites publishing, see Understanding Publishing in Administering Oracle WebCenter Sites.
To publish an approved asset from the Contributor interface:
Publishing Assets from the Search Results List
If you are assigned the Publisher role, and you want to publish multiple assets from the Contributor interface, you can trigger a bulk publish from the search results list.
Checking the Status of Your Publishing Sessions
After you have published at least one asset with the publish feature in the Contributor interface, you can check the status of that publish session, and any other publish sessions you ran from the Contributor interface since the last time the administrator cleared the publish history console from the Admin interface.
Revision Tracking
This section describes revision tracking and the procedures used to track assets, illustrated with examples from the avisports sample site. Revision tracking is an optional feature which must be enabled by the WebCenter Sites administrator for the asset types on your sites. Revision tracking allows you to track and control the changes made to your assets.
With revision tracking, you can:
-
Enforce that only one person at a time can edit or delete an asset.
-
Track and view past versions of an asset and the users who worked with the asset.
-
Restore (roll back) an asset to a previous version.
This chapter includes the following sections:
Note:
Contact your administrator if you have any questions or concerns about revision tracking as it applies to you.
Checking Out Assets
This section shows you how to manually check out an asset displayed in Form View and Web View.
Note:
If the asset is checked out to another user, when you try to edit the asset or check the asset out, you receive an error message like the one below:
![Message displayed when an asset is already checked out. Message displayed when an asset is already checked out.](img/revtrack_checkedout.png)
For information about checking out assets, see these topics:
Examining Your Checkouts
A list of assets that are currently checked out to you is accessible from your dashboard (in the Home tab).
To view the assets currently checked out to you:
Undoing a Checkout
This section shows you how to undo the checkout of an asset. Undoing a check out makes the asset available to other users who have permissions to work with it.
For information about undoing a checkout, see these topics:
Undoing the Checkout of an Asset Displayed in Form View
To undo the checkout of an asset displayed in form View:
Checking In Assets
This section shows you how to check in an asset displayed in Form View and Web View. Checking an asset in creates a new version of the asset and makes it available to other users who have permissions to work with the asset.
For information about checking in assets, see these topics:
Examining Published Revision History
You can examine the published revisions of an asset and see all the versions of the asset that are published to a publish destination.
Reverting to a Previous Version (Rollback)
This section shows you how to roll an asset back to a previous version.
Note:
You cannot revert to a previous version of an asset if:
-
Revision tracking is not enabled for the asset type.
-
The asset is checked out by you or another user. To roll the asset back, it must be checked in.
-
The version to which you want to roll back is the first (SYSTEM) version of the asset.
If you have questions about revision tracking or your permissions, contact your WebCenter Sites administrator.
To roll back an asset:
Participating in Workflow
This section describes workflow concepts and procedures on how to perform specific tasks related to workflow.
For information about basic workflow concepts and terminology, see About Workflow.
For more information about participating in workflow, see:
Viewing Your Assignments
To manage your workload, you can view a list of your current assignments and their status by accessing the Assignments section of your dashboard (located on the Home tab).
Note:
As you work in the interface, new assignments might be given to you, and you may complete some of your current assignments, causing your assignment list to change. Check your assignment list periodically to make sure you stay up to date with your assignments.
To view a list of your workflow assignments:
Using Workflow Functions
The following sections describe the workflow functions you use in the Contributor interface. These functions are available from the menu bar (select View, and then select Status) when you are working with an asset. Depending on your function privileges, some functions described in this section may not be available to you.
For information about using workflow functions, see these topics:
Assigning an Asset to a Workflow
An asset can be assigned to a workflow either automatically or manually.
Automatic workflow assignment is set up by the administrator for selected asset types. When you create an asset of such type, the asset is automatically placed in the workflow process assigned to that asset type. Consult your administrator to find out which asset types are set up for automatic workflow assignment.
Manual workflow assignment is available to users with the appropriate permissions, assuming a workflow process is assigned to the selected asset type.
To manually assign an asset to a workflow:
Note:
Before an asset can be assigned to a workflow, the administrator must first assign one or more workflow processes to the asset type of the asset in question; otherwise, the option to assign the asset to a workflow is not available. Consult your administrator to find out which workflow processes are available to which asset types on your system.
Setting a Process Deadline
A process deadline is the overall time allotted for an asset to pass through a workflow process. By default, no process deadline is set. This deadline is independent of the assignment deadline described later in this section; that is, the total of the individual assignment deadlines does not necessarily add up to a process deadline.
Note:
Deadlines are informational only. The system does not impose any sort of penalty or issue error messages when a deadline is exceeded.
Before you can set a process deadline, the workflow administrator must first have done the following:
-
Allowed a process deadline to be set for this workflow process.
-
Assigned you a workflow administrator role for the workflow process, or otherwise provided you with the right function privileges.
The option to set a process deadline is available only if both of the above conditions are met. Contact your administrator to find out if you have the appropriate privileges and whether setting a process deadline is enabled for the workflow process in question.
To set a process deadline:
Setting an Assignment Deadline
An assignment deadline is the time allotted to the assignee to complete an assignment as an asset advances through workflow. This deadline is independent of the process deadline described earlier in this section; that is, the total of the individual assignment deadlines does not necessarily add up to a process deadline.
Note:
Deadlines are informational only. The system does not impose any sort of penalty or issue error messages when a deadline is exceeded.
Before you can set an assignment deadline, the workflow administrator must first have done the following:
-
Allowed an assignment deadline to be set for this workflow state.
-
Assigned you a workflow administrator role for the workflow process, or otherwise provided you with the right function privileges.
The option to set the assignment deadline is available only if both of these conditions are met. Contact your administrator to find out if you have the appropriate privileges and whether an assignment deadline is allowed for the workflow state in question.
To set an assignment deadline:
Note:
This procedure describes how to set an assignment deadline from an asset's Inspect view. You can also set an assignment deadline when you complete an assignment for an asset. In such case, the Finish My Assignment form includes an Assignment Deadline field.
Finishing Your Assignments
After you complete your work for an assignment, you have to notify the system that you are finished so the asset can continue to move through the workflow.
To finish your assignment for an asset:
What happens after you complete your assignment depends on the way the administrator set up the next workflow step. The following are five possible options:
-
Assign From a List of Participants — when you (or another user with the appropriate privileges) assign an asset to a workflow, you have the option to decide which participants in each role get the assignment when the asset enters a workflow state requiring those roles. This is the default mechanism for moving an asset through a workflow.
-
Choose Assignees When Step is Taken — this option, is similar to the Assign From a List of Participants option described earlier, but instead of predetermining at the beginning of the workflow who gets the assignment during which workflow state, you choose assignees for the next workflow state in real-time each time you take a step.
-
Retain From State Assignees — you keep the assignment as the asset moves to the next state; this allows you to continue working on the asset in that state.
-
Assign To Everyone — the asset is assigned to all users holding roles participating in the current workflow process.
-
No Assignments — as the asset moves to the next state, it remains in the workflow so that function privileges defined for the workflow process are enforced. However, the asset is assigned to no one and participant roles alone (through their assigned function privileges) determine who can work on the asset, and how.
Delegating Your Assignments
As you review your assignment list, you might find that you are unable to complete certain assignments. For example, you might notice that an assignment's due date falls during your scheduled vacation time. In such situations, you can delegate your assignment to another user who has the same role as you, assuming that the user does not have an identical assignment for the asset; that is, if both you and another user have the Editor role, you cannot delegate the asset to the other user if he/she has the asset assigned through the Editor role. (The asset can still be assigned to the user through a different role or another workflow process.)
To delegate an assignment:
Abstaining from Voting
Sometimes, you are unable to deal with a particular assignment: your workload is too heavy, or perhaps you have been miscast in your role. In such situations, you can abstain from voting (that is, waive your participation), if yours is not the last (or only) vote for that particular role, or step, or both. When you abstain, you still have the assignment, but the asset can continue through workflow.
To abstain from voting on an assignment:
Resolving Deadlocks
A deadlock can occur when multiple steps are available to move the asset to the next state, and each step requires all assignees to vote. If the vote is not unanimous in favor of a single step, a deadlock occurs.
Frequently, resolving deadlocks involves offline communication and negotiation among assignees to achieve consensus; as such, deadlocks cause additional work for everyone involved and should be avoided whenever possible. If a deadlock occurs, it should be resolved as quickly as possible so that the flow of work suffers minimal delay.
To resolve a deadlock, certain participants must change their votes to achieve unanimity. If you receive an e-mail notification that your vote is the one causing the deadlock, you must vote again to break the deadlock.
To resolve a deadlock, do one of the following:
- Vote again on the assignment and select to finish it, as described in Finishing Your Assignments.
- In some cases, you can also resolve the deadlock by changing your vote to an abstention, which clears the way for the asset to move to the next workflow state (see Abstaining from Voting).
Removing an Asset from Workflow
You can remove an asset from workflow assuming you have the permissions to do so. When you remove an asset from workflow, all assignments for the asset are cancelled.
To remove an asset from workflow:
Setting Workflow Participants
When you have placed an asset in a workflow and chosen the assignees for each role in the workflow process, you might find that you forgot to include a certain user as an assignee for a particular role. Or perhaps you realized that you gave the assignment to a certain user by mistake. In such cases, you can modify the list of participants for an asset while the asset is in workflow.
To set workflow participants: