Stage Name |
Type the descriptive text that
will identify the stage. This name can be
up to 40 characters in length, and may contain
any characters that can be displayed in HTML. The Stage Name appears
on the WSD Application Desktop, in reports and notification
messages, and in other areas of WSD that
list or refer to workflow stages.
- We recommend that you
assign a descriptive name, preferably one that matches your workflow.
For example: Design, Typeset, Editing, Formatting, Policy Review, Author
Correction, Author Review, Final Review,
etc.
|
Position |
This field is provided to
help you select the order in which the stages are listed on the Application Desktop.
The drop-down list contains the following options:
- First - select this option if the stage will be
the first
stage in the workflow stage list on the
Application Desktop screen (immediately following your Submissions
stage), depending on the user's permission to see
and/or access this stage.
- Last - select this option if the stage will be the last
stage in the workflow stage list on the Application Desktop screen,
depending on the user's permission to see and/or access this
stage .
- After <stage name> - this option allows you
to select the name of the stage that will immediately precede the stage you are
adding.
|
Stage
Type |
Select the Stage Type to be assigned to
the new stage. The Stage Type is determined by the purpose and
approval requirements for the stage you are adding:
- Author -
Only the person designated as the author of a request can Edit,
Approve or Disapprove a request in an Author 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 one of these users
approves/disapproves the document, it will automatically move to the
next/previous designated stage.
- 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. Approvals by different groups can occur concurrently. A
group should not be added until the stage to which it will be assigned
has been added.
|
Notification
E-Mail Template (Author Stages
only) |
If you
selected Author as the Stage Type, you must decide if
you want the designated author to receive an immediate notification when a
request is submitted or approved into this stage. Select the E-Mail Template to be used when notifying
authors
that their content has entered an Author stage, or select "None" if no
notification message is to be sent. WSD provides sample
templates that you may edit via the Template Maintenance
screens. |
Required
Request Fields |
Select the
information that must be present before content can be approved to the
stage you are adding.
- Filename Path: identifies the path and
filename
of the request when it is published to the public web site. 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. The
information in the Filename field is referenced by the
<$filename> template variable. [Filename:] on the Properties
screen.
- Submitter:
identifies the person submitting the request. It is recommended that it
be a required field for any workflow stage into which requests are
submitted, so that reviewers and approvers know who submitted the
request. This information can be viewed [Submitted By:] on the
Properties screen.
- Author:
identifies the author of 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. The information
in the Maintainer field is referenced by the <$maintainer>
template variable. [Maintainer:] on the Properties screen.
- Request Type: identifies one of the request types valid for
publishing content: Add, Modify, Move, Copy, Rename, or
Delete. This Requirement should not be set for workflow
stages where a request of type Unknown or Email can be
submitted. Because Unknown and Email are not valid (publishing) Request
Type:s, the Request Type must be changed to one of the other six types
before the request is approved to any stage for which a valid
(publishing) Request Type: is required. You may choose to make it a
required field for any stage preceding the Publishing Stage. Request
type can be viewed and/or changed [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 Request , Copy Request and Move
Request screens.
- Next Revision
Number: identifies the revision number for any asset. For new
content, the Revision Number is set to 1.0. This number is
automatically incremented by 0.1 each time a request (Add, Modify, etc.)
is submitted for that content; not when the content is published. 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.
|