git-svn-id: https://192.168.0.254/svn/Proyectos.Incam_SGD/tags/3.7.0.2_original@1 eb19766c-00d9-a042-a3a0-45cb8ec72764
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>
|