PLANNING WORKFLOW
(STAGES, GROUPS AND APPROVAL CLASSES)

Before you start using WebSite Director (WSD) to manage your workflow, it is important that you plan your Workflow Groups, Workflow and Group Stages and Approval Classes. The following tutorials are also important references in planning your workflow:

STEP 1: PLAN YOUR WORKFLOW STAGES AND GROUP STAGES

The first step is to plan your stages. Group Stages will be required when you plan to use Groups for approving content. Stages and groups within Group stages will be selectable when you define your Approval Classes.

During installation, WSD creates one default Workflow Stage - Initial Entry - which has a Stage Type of Individual. It will be the only stage in your approval processing until you add additional workflow stages. Note: You may change the name, type and options for any stage using the Edit Stage screen.

Each User's "My Pending Requests" Stage

WSD provides a workflow stage specific to each user, to allow users to save requests outside of the defined workflow. These stages are not visible to any other user except for users who have been granted System Administration permission (see User Permissions). There are several ways that a document can be placed into a user's "My Pending Requests" Stage:

When the user Saves (not Submits) a request on any Add/Upload Document screen.
When any Add New Request screen is abandoned, or WSD is terminated before the user Saves or Submits a new request, WSD places the document into the user's "My Pending Requests" Stage.
When "Pending Requests" is listed as the Default Submission Stage assigned to the Approval Class associated with the request.
When "Pending Requests" is listed as the Auto Submission Stage assigned to the Approval Class, and the request was created automatically by WSD.
When a request is disapproved into the "My Pending Requests" stage using the Disapprove screen.

Note: Requests in the user's "My Pending Requests" stage can be approved into the workflow at a later date/time, or disapproved into the Trash Bin.

Planning Form for Workflow Stages

It is important that you plan your Workflow Stages before you begin adding them. This will allow you to plan the order of your workflow, and select the Required fields. The following form contains all of the information on the Add New Stage screen. Note: WSD assigns a "Stage ID" value shown on the Edit Stages screen. This ID is displayed here for the use of developers in most of the external API commands that refer to WSD Stages.

Stage Name (1) Stage
Pos.
(2) Stage Type (3)
Notification E-mail Template
(Author Stages Only)
(4)
Required Request Fields (5)&nsp;

File-
name Sub-
mitter Author Main-
tainer Req.
Type New
File-
name Next
Rev.
No.

Workflow Stage Definitions

(1) Stage Name
The Stage Name appears on the WSD Application Desktop, reports, notification messages, and other areas of WSD that list or refer to workflow stages. This name can have up to 40 characters, and may contain any characters that can be displayed in HTML. We recommend that you assign a descriptive name to each stage, preferably a name that matches your workflow. For example: Design, Typeset, Editing, Formatting, Policy Review, Author Correction, Author Review, Final Review, etc.

(2) Stage Position
The Stage Position designates its location in the workflow stages list, and is assigned when you Add the stage. This position cannot be changed once the stage is added. If a stage is not in the proper position after all stages have been added, you can delete the stage and re-add it.

The following options are available to designating the stage's position in the workflow stages list:

First - the new stage will be the first stage in the workflow stage list on the WSD Application Desktop, immediately following the user's Pending Stage.
Last - the stage will be the last stage in the workflow process, immediately preceding the Publishing stage.
After <stage name> - Using the drop-down list of stages, select the stage that is to immediately precede the stage you are adding.

(3) Stage Type
You must assign one of the following Stage Types to each stage, depending on the purpose and approval requirements of the stage:

Author - Only the person designated as the author of the request can approve or disapprove the request in this stage. Users with "Update Documents in Author Stages" permission (see

User Permissions

) may edit, approve or disapprove requests in any stage designated as an Author Approval stage.

Other WSD users may be able to view requests in an Author stage if they have been given View-only access (see User Permissions "Workflow Permission"); however, they will not be able to edit, approve or disapprove the Author's request.

Individual - One or more users can be authorized to edit, approve, disapprove or view requests in this stage, as an individual. When any one of these users approves/disapproves a request, it will automatically move to the next or First workflow stage defined for the Approval Path assigned to this request.

Group - One or more groups of users can be authorized and may be required to approve or disapprove a request in this stage.

There can be one or more users in each group
Any member of a group may approve or disapprove on behalf of the group. Requests remain in a group workflow stage until either:
- All required groups have approved the request OR
- The first time a group disapproves the request
Approvals by different groups can be made concurrently.

(4) Notification E-Mail Template (Author Stages Only)
If you selected Author Approval Type above, you may select one of the available templates in the drop-down box. (Note that WSD provides sample templates. You may edit these templates via the Maintain Templates screens).WSD will use the template you select when building messages to notify document authors that their documents have entered the Author stage. Leave this field set at "None" if you do not want a notification message sent to the author.

(5) Required Request Fields
These check boxes determine the information required before a request can be approved to this stage (i.e., the information must be provided in a previous stage). For the Submitter, Author, and Maintainer fields, the name must be selected from a drop-down list of authorized WSD Users. These fields will be displayed on the Properties screen for each work-in-progress request.

Filename: identifies the path and filename of the request when it is published to the public web site. It is a required field for the Publishing Stage, however, you may make it a required field for any stage preceding the Publishing Stage. The information in the Filename field is referenced by the <$filename> template variable. [Filename:] on the Properties screen.

Submitter: identifies the person submitting the document. It is recommended that it be a required field for the stage immediately following the Initial Entry stage, so that reviewers and approvers know who submitted the document. [Submitted By:] on the Properties screen.

Author: identifies the author assigned to the request. It must be a required field for all Author stages so that WSD knows which user can modify, approve and disapprove the request. The information in the Author field is referenced by the <$author> template variable. [Author:] on the Properties screen.

Maintainer: identifies the person responsible for updating the request after it is published. Unlike the Author property, WSD does not provide any special processing capabilities for this field. The information in the Maintainer field is referenced by the <$maintainer> template variable. [Maintainer:] on the Properties screen.

Request Type: identifies one of the listed request types: Email, Add, Modify, Move, Copy, Rename, or Delete. Because Email is not a valid Publishing request types, this Request Type must be changed to one of the other six types before the request can be approved to the Publishing Stage. You may choose to make the Request Type a required field for any stage preceding the Publishing Stage. [Request Type:] on the Properties screen.

New Filename: identifies the new filename for a MOVE, COPY, or RENAME request. It must be a required field for the Publishing Stage. However, you may make it a required field for any stage preceding the Publishing Stage. [New File Path and Name:] on the Rename, Move and Copy Request screens.

Next Revision Number: identifies the revision number for any asset, beginning with 1.0. This number is automatically incremented by the system default increment each time a request (Add, Modify, etc.) is submitted for that asset; not when the asset is published. The installed system default increment is 0.1 and can be changed by the System Administrator. While a request is being processed, the revision number can be changed manually, but only to a *larger* number. The information in the Next Revision Number field is referenced by the <$revision> template variable. If you do versioning, this should be a required field. [Next Rev #:] on the Properties screen.

STEP 2: PLAN YOUR WORKFLOW GROUPS

The next step in installing and setting up your WSD workflow is to define any groups, and what functions they will be responsible for. This includes submitting, editing, reviewing and/or approving new content, and changing existing content. As you can see from the following form, you can list enter a name for each group, describe their approval responsibilities, and then assign them to a Group Stage.

Note: WSD assigns an internal "Group ID" to a new group when it is added. The internal Group ID is used by template designers and application developers for their use in most of the external API commands that refer to WSD groups, in the "group= " Layout Template attribute, and the "groupmember" template conditional tag.

Group Name (1) Remarks: This Group is responsible for... (2) Assigned to Group Stage... (3)

Workflow Group Definitions

(1) Group Name
The Group Name appears on all screens referencing workflow groups.This name can have up to 40 characters, and may contain any characters that can be displayed in HTML. We recommend that you assign a descriptive name to each group, preferably a name that represents the responsibility of that group. For example: Company Policy, Human Resources, Engineering, etc.

(2) Remarks
This field is provided on the form to define a context for how this group will be used within WSD. We recommend the following:

Restrict - Restrict who can edit fields on a Page Layout Template. Note: Fields that can be updated only by members of a specific group (as defined by the Template designer) will appear as View Only to users who are not members of the assigned group when requests are edited.
Approval - Used only to provide approval permissions for assigned groups.
Both - Used both for group approval and field editing restrictions on Page Layout Templates.

(3) Assigned to Group Stage...
A list of Group Stages for which this group has approval permissions.

STEP 3: PLAN YOUR APPROVAL CLASSES

This step is the final one in your planning, and is crucial to the definition of your workflow. Using the Groups and Stages that you have defined above, this form allows you to you plan the order of your workflow and select the Required Workflow Stages. The form contains all of the information on the Add New Stage screen.

Class Name (1)

Default Submission Stage (2)

Auto Submission Stage (3)

Approvals Needed
Required Stage (4a)

Required Stage
Submit (4b)

Required Stage
Prior (4c)

Approval Class Definitions

(1) Class Name
The descriptive name of the Approval Class.

(2) Default Submission Stage
This is a Required field selected from a drop-down list of existing stages. The stage selected here will be the one into which new requests will be submitted, and must be selected as Required under Approvals Needed (see below).

(3) Auto Submission Stage
This is a Required field selected from a drop-down list of existing stages. The stage selected here will be the stage into which automated Delete/Modify requests will be submitted by the WSD "Cleanup Database" module, usually scheduled to run on a rebular basis by the System Administrator. See Scheduled Processes.

(4) Approvals Needed: This selection has three columns: Required, Submit and Prior.

(a) Required � This column lists the existing Workflow Stages for your site, and allows you to select one or more Stages (or Groups within Group Stages) that are Required for the Approval Class.

You must check the Required checkbox for the stage selected as the Default Submission Stage (see item 2).
If you do not select any stages as Required, users assigned to the Approval Class will only be able to Submit a request directly to Publishing, or Save it to their "My Pending Requests" stage.

(b) Submit � This box must be checked if you want users to have the ability to submit requests into the associated stage when submitting new requests.

(c) Prior � When this option is selected, and any user modifies the content, the request can only be approved to a prior stage in the Approval Class, or to the Submitter�s "My Pending Requests" stage.

Copyright 2000-2005 CyberTeams, Inc., http://www.cyberteams.com All rights reserved.
CyberTeams and WebSite Director are registered trademarks of CyberTeams, Inc. All other marks are the property of their respective owners.

Stage Name (1)	Stage Pos. (2)	Stage Type (3)	Notification E-mail Template (Author Stages Only) (4)	Required Request Fields (5)&nsp;
Stage Name (1)	Stage Pos. (2)	Stage Type (3)	Notification E-mail Template (Author Stages Only) (4)	File- name	Sub- mitter	Author	Main- tainer	Req. Type	New File- name	Next Rev. No.

Group Name (1)	Remarks: This Group is responsible for... (2)	Assigned to Group Stage... (3)

Class Name (1)	Default Submission Stage (2)	Auto Submission Stage (3)	Approvals Needed Required Stage (4a)	Required Stage Submit (4b)	Required Stage Prior (4c)