# Chapter 3 - Constraints: Specifying Users
# 3.1) General
This chapter addresses the notion of constraints which refer to the profiles of those who can intervene in a workflow document at a particular state. This is in contrast to Chapter 2 which dealt exclusively with the routing of workflow documents between states. Constraints are defined in terms of roles or fields, each of which must in turn resolve to a set of user names. Only those users defined in The following RIs can intervene (see the graphic below) are allowed to modify the document for that particular document state. So in the following example, when a workflow document belonging to process DOC205 is in state Manager, only the users whose names are contained in the corresponding workflow document field Manager can intervene (i.e., affect any modifications to that document).
Note that it is strictly a coincidence that the state name and the constraint names are identical. Different constraints can also be defined in the same document (see Selective Operations).
In the workflow document, field WACurrentAuthors contains the list of users authorized to modify the document at that moment in time (field WACurrentAuthorsDisplay is what is displayed in the view). If a given user cannot edit a workflow document at a given state, it is because he or she is not listed in WACurrentAuthors.
If a workflow document is unexpectedly archived, this normally indicates that there were no valid user names in the state being routed to (an error condition).
# 3.2) Roles
Purpose
Role constraints refer specifically to Domino roles and Role documents. The latter are contained in view Workflow - Roles from which the ACL can be managed directly via the button Update ACL. Role constraints must only be used in the initial State document $created$ and only role constraints should be used therein. If role [*] is used, then any user can create a document for that process. If specific role names are specified, then only users belonging to those roles_ (with the exception of [WAManager]) are allowed to create workflow documents of that type. In example DOC203 below, yellow from Marketing and green from Sales have both created a document followed by selecting the Send button.
What it looks like
The above graphic to the left displays the available document creation choices for the Marketing and Sales people. In the graphic just underneath this, however, note the absence of DOC203 from the list of choices presented to user b1 (who doesn't belong to either of these two groups).
How to make it happen
Additional Notes / References
Video: 3.2 Roles
Application: WAApplication02.nsf, Process DOC203
# 3.3) Fields
Purpose
Field constraints refer to field names contained in the corresponding workflow documents and Field documents. The latter are contained in view Workflow - Fields. Field constraints should be used in every State document with the exception of initial state $created$. The corresponding fields in the workflow documents must contain one or more valid user names. In example DOC204 below, users d1 and d2 are designated as the responsible individuals (field constraint Manager) in state Manager.
What it looks like
How to make it happen
Additional Notes / References
Video: 3.3 Fields
Application: WAApplication02.nsf, Process DOC204
# 3.4) Roles and Fields
Purpose
Role and Field constraints can be used in harmony. With the exception of the initial state, all constraints in the workflow must resolve to fields containing user names. Since Field constraints are tied to the process version (and thus would require the recopying of user names between these documents), Workflow Ascendant provides a system to use roles which are independent of that. In example DOC205 below, user orange is designated as the responsible individual (field constraint Manager which derives from role Manager) in state Manager (note that while the state name happens to be the same as that of the constraint in this example, they are in reality completely independent).
What it looks like
How to make it happen
Additional Notes / References
Video: 3.3 Roles and Fields
Application: WAApplication02.nsf, Process DOC205
# 3.5) User Stack
Purpose
Workflow Ascendant provides the ability to implement a user stack from an organizational hierarchy. This hierarchy can be defined in the view OU By Hierarchy in OU documents or this information can be taken from an external source (in that case you would replace #waSetUsersMGR below with your own routine). To note that the system accounts for hierarchies of dynamic lengths. In this particular example, user a1 creates and sends a DOC206 document into the workflow where it progresses through the user's approval hierarchy.
What it looks like
How to make it happen
Additional Notes / References
Reference Section 4.2 for explications regarding workflow document initialization.
Video: 3.4 User Stack
Application: WAApplication02.nsf, Process DOC206
# 3.6) State Stack
Purpose
Workflow Ascendant provides the ability to implement a state stack using Actions and an Extended Sequential Operation. The latter, also referred to as a Virtual State, essentially acts as a subroutine which is called by the other states. In the example below, the workflow for Marketing is State 01 to State 02 to State 03 while that for Sales is State 03 to State 02 to State 01. These stacks are initialized when the document is first advanced in the process and reset in State document To be modified (not shown below).
What it looks like
How to make it happen
Additional Notes / References
Video: 3.5 State Stack
Application: WAApplication02.nsf, Process DOC207
# 3.7) External (ERP, RDBMS ...)
Purpose
Workflow Ascendant provides the ability to pull users in from an external data source. This external source could be an ERP, a relational database or any number of other directories where user information is stored. To implement extracting users from an external source, you simply complement the built-in mechanisms of Workflow Ascendant with your own.
What it looks like
[This applies to any of the previous examples in this Chapter which all happen on the back-end.]
How to make it happen
Additional Notes / References
Reference Section 4.2 for explications regarding workflow document initialization.