# Chapter 6 - General References
# 6.1) General Web Interface
# 6.2) Notes Admin Interface
The various graphics below present the development administration interface as it relates to managing the process.
# 6.3) Workflow Document
[]{#_6.4)_Delegation_Document .anchor}
# 6.4) Delegation Document
Workflow Ascendant provides real-time delegation. Users create a Delegation document for themselves indicating the time frame of their absence along with the person to be designated to. The database manager can create Delegation documents for others. When the delegation becomes effective, the delegated to party receives an email to that effect (and vice-versa when the delegation period has passed).
# 6.5) Admin ACL Entry Document
ACL Entry documents provide a centralized access to the database global access rights. Any changes you make here should be followed by selecting the Update ACL button. You will want to set the Server document to the name of your server and the Managers document with the names of all those required to manage the application. For application specific roles, reference Section 6.10. To note for Workflow Ascendant to properly control who can modify a document at a given point in the process, those who intervene must be set access level Author (the default as set below).
# 6.6) Admin Field Document
Each constraint used in a given workflow must contain a corresponding Field document for the delegation function to work properly. As in most Workflow Ascendant Admin documents, these are defined by Version and Form Name. For processes already in production, any changes to this list should only be done in the context of a new workflow version (e.g., V02).
# 6.7) Admin Gantt Task Document
Gantt Task documents form the task list to be used in creating Gantt charts. Use these in conjunction with Subform content_DocWFGantt and Custom Control content_DocWFGantt. For a chart to be rendered displayable, all default dates (01-01-2000) must be set to a different value (which will turn the ready indicator from yellow to green). As in most Workflow Ascendant Admin documents, these are defined by Version and Form Name. As these documents are only accessed upon workflow document creation, any changes to this list will not require enacting a new workflow version (e.g., V02).
# 6.8) Admin Language Document
The active Language document dictates much of the behavior of Workflow Ascendant. The graphics included below illustrate options that affect basic operations. All other sections here provide you the opportunity to rename objects displayed in the application - or even create a new Language document to display all in the language of your choice.
# 6.9) Admin Reference Document
Reference documents provide a means to allocate a unique and sequential reference to workflow documents. This ensures a consistent way to identify documents and verify that none are missing (note that a workflow document should never be deleted -- only archived). References are virtually always required to be assigned to a workflow document when it is first launched into a process (as in the example below) but you can specify a different state if desired.
# 6.10) Admin Role Document
Role documents should generally be used in conjunction with Field documents. With the exception of the initial state, all constraints in the workflow must resolve to fields containing user names. To properly implement this Role-Field system, include #waSetUsersRole in initial State document $created$ and name the following identically:
Field Doc. Example: CEO
Role Doc. Example: [CEO]
Field in the workflow document: CEO (multivalued: Name type in Notes, Text type in XPages)
In this example then, field CEO will automatically be set to blue/Horizon when the document is created, keeping in mind however that this information is taken from the Role document -- not the ACL. Updating the ACL allows for proper handling of the initial state only.
# 6.11) Admin State Document
A State document dictates how a workflow document is to respond at that state. A collection of State documents represents the application process. In the example below, the document is initialized by routine #waInitModFields when Manager opens the workflow document. In selecting the button Send, there are 3 choices to choose from: To be modified, Rejected and Approved. If the latter is selected and field Total in the workflow document is set to 1000 and routine #waCntMandFields does not flag an error (rule b), then the workflow document is updated from the Actions tab (field CommentsLabel01A, ...), the default email from the Language document is sent (as the Subject and Body fields are left blank) to those responsible to intervene in the next state (*N = Next), and the document is routed to state CEO.
# 6.12) Admin Time Trigger Document
Time Trigger documents define actions to be taken when a document resides in a state (or in a series of states) for a designated amount of time. In the example below, if a workflow document belonging to process DOC202 remains in any state for 3 days, then an email is sent to those who haven't yet intervened (contained in field WACurrentAuthors) with Director on cc, an alert is set in the view (view document field WADelayIcon) and WAChartCount01 is updated with the names of the "guilty parties" (a statistics monitor -- you can create your own).
