65 lines
3.3 KiB
HTML
65 lines
3.3 KiB
HTML
|
<html>
|
|||
|
|
<head>
|
|||
|
|
<title>Workflow</title>
|
|||
|
|
</head>
|
|||
|
|
|
|||
|
|
<body>
|
|||
|
|
|
|||
|
|
<h2>Workflow</h2>
|
|||
|
|
<p>Workflow may be defined as the process a document goes
|
|||
|
|
through to serve its purpose in an organization. For example, an invoice is
|
|||
|
|
created, distributed, then paid; a report may be created, reviewed, edited, and
|
|||
|
|
distributed. </p>
|
|||
|
|
<p>Some documents, such as tenders, may have complex
|
|||
|
|
workflows, requiring input from several people within and outside of your
|
|||
|
|
organization before the work is complete. </p>
|
|||
|
|
<p>The KnowledgeTree administrator defines and manages
|
|||
|
|
document workflows in DMS administration, and any KnowledgeTree user may be
|
|||
|
|
involved in a document workflow. </p>
|
|||
|
|
<p>Workflows in KnowledgeTree involve three key areas:</p>
|
|||
|
|
<ol>
|
|||
|
|
<li><a href="#assign">Assigning workflows</a></li>
|
|||
|
|
<li><a href="#states">States and Transitions</a></li>
|
|||
|
|
<li><a href="#effects">Workflow effects (Actions)</a></li>
|
|||
|
|
</ol>
|
|||
|
|
<h3><a name="assign"></a>Assigning workflows</h3>
|
|||
|
|
<p >A document in the repository can have
|
|||
|
|
only one workflow attached to it at any given time. By default, workflows are
|
|||
|
|
not automatically attached to new documents when theyre added to the
|
|||
|
|
repository. However, the administrator may configure the system to assign
|
|||
|
|
workflows when new documents are created, or to assign workflows only to
|
|||
|
|
specific documents. Users are also allowed to select and assign workflows to the
|
|||
|
|
documents they are working with provided they have the permissions to do so.
|
|||
|
|
</p>
|
|||
|
|
<h3><a name="states"></a>States and Transitions</h3>
|
|||
|
|
<p >Workflows consist of states and
|
|||
|
|
transitions. A state may be defined as a stage in a documents lifecycle, such
|
|||
|
|
as billed or draft. Each workflow has a starting state, which is the initial
|
|||
|
|
state for any document in a workflow.</p>
|
|||
|
|
<p >Transitions, which may be defined as the
|
|||
|
|
way in which documents move between states, are an essential part of the
|
|||
|
|
workflow. Each state can have one or more transitions, depending on how the
|
|||
|
|
administrator has created the workflow.</p>
|
|||
|
|
<p >Transitions point to the next step in
|
|||
|
|
the workflow, such as send to client or review, which effectively changes the
|
|||
|
|
state of the document. Transitions represent the actions that may be performed
|
|||
|
|
on a document. For example, an invoice starts in the generated state; then it is
|
|||
|
|
sent to client, before it is marked as billed. Transitions are said to be
|
|||
|
|
guarded not all users are allowed to access them. In a publication workflow
|
|||
|
|
for example, only users with the role reviewer would be allowed to review a
|
|||
|
|
document, and to move it from draft to published.</p>
|
|||
|
|
<h3><a name="effects"></a>Workflow effects (Actions)</h3>
|
|||
|
|
<p >Workflows are more than just states and
|
|||
|
|
transitions. Users and administrators use workflows to restrict, deny or grant
|
|||
|
|
access to documents in the repository, based on the documents position in the
|
|||
|
|
workflow. For example, a state can restrict both actions and permissions on a
|
|||
|
|
document only reviewers may be allowed to discuss draft documents for
|
|||
|
|
instance, while clients will be disallowed from viewing unbilled invoices, and
|
|||
|
|
published documents will be prevented from being checked in or checked out of
|
|||
|
|
the repository. Additionally, users in specified Roles or Groups can be notified
|
|||
|
|
when a document reaches a certain state in a workflow. These notifications
|
|||
|
|
display on the Dashboard and are emailed to users with specified email accounts.</p>
|
|||
|
|
|
|||
|
|
</body>
|
|||
|
|
</html>
|