Page tree

Documents Table

The Documents table can be used to manage the creation and publication of documents of various types, from marketing collateral to employee procedure manuals. A light-weight parallel publication approval process is included.

Examples of documents that can be included: FAQs, official memos, company policy/procedure, marketing collateral, user manuals, newsletters, press releases, and so on. The Documents table can be used to manage documents that are:

  • Accessed through Agiloft, using the records in this table
  • Published at the company website, intranet, or documented and distributed.

Access to documents is controlled through permissions that are based on a choice field within the Document record.

Use Case

The following sections contain information on how end users and technicians can submit Document records, as well as how the Document Management team processes submitted records. Document records are generally created in a default status of Draft. After supplying the required information and uploading a document, the user clicks the Submit for Review button to begin the review process. The status of the record will be updated to Pending Document Manager, and the contact information fields are automatically populated based on the details in the user's record. If the user is not prepared to submit the record immediately, they can save the record until they are ready to make further updates. When a user submits a record, they are referred to as the Submitter. Both end users and power users can submit records:

  • End Users belonging to the Document Creator team can create Document records through the End User Interface (EUI). Action buttons are provided so that the end user can move the document through the workflow. 
  • Power Users belonging to the Admin, Document Management, and Document Creator groups can submit Documents records. Support Staff members can also convert Incident or Service Requests into new FAQ documents. Only Admins and Document Managers can update the status of a Document record manually. All other groups will use Action Buttons to move the document through the workflow.

Processing Records

When a document record is submitted, the Document Management Team is assigned by default and notified. A Document Manager reviews the document for content and formatting, and determines if the document requires additional review. If there are any issues with the initial document, the Document Manager clicks Return to Submitter to send the document back to Draft status. A rule then notifies the Submitter that the document requires revision. The user makes appropriate updates to the attached document or the Document record itself, then clicks Submit for Approval again.

Handling Approvals

The Requires Approval field on the Progress tab determines whether approvals are needed before publication.

If the document does not require approval by document Approvers, the Document Manager clicks the Publish without Approval button. The Submitter is notified that the document has been published. If the Requires Approval field is set to Yes, a validation rule notifies the Document Manager that approval is required if the Document Manager attempts to publish without approvals.

Selecting Approvers and Creating Approvals

If the document requires approvals by document Approvers, the Document Manager selects them by adding approver names under the Potential Reviewers heading on the Progress tab. This field is a link to a single field, called Full Name, with multiple values enabled in the Employee table. It is displayed as a multiple value box with a pop-up selection list, which is filtered to only list people on the Document Reviewers Team.

After selecting the appropriate Approvers, the Document Manager clicks Submit for Approval or manually changes the Status of the record to Pending Approval. A validation rule checks to see if the Document Manager has actually added Approvers to the record.

When the record is saved, an Approval record is created for each person named in the Approvers field by a conversion process from the Approver's Employee record. A linked record action updates the Last Document ID field in the Employee record.

When the system detects a change in the Last Document ID field, it performs a data conversion action using the Employee record to create an Approval record. The Approval record is linked to the Document record through the mapping of the Last Document ID field to the linked Document set in the Approval record. Additional approvers can be added during the approval process, although automation rules and actions prevent the creation of multiple Approval records for existing approvers.

The default Approval Status for new Approval records is Pending Approval. When an Approval record is created, the approver is automatically notified that they have a document to review and approve. In the Approval record, the linked field set from the Document record includes a hyperlink to the document using the view only source field display option for the Documents field under the Attachment heading. The approver can click the link to open the document, which allows the approver to mark up the document. Then, the document can be uploaded to the Approval record. Approvers are not able to upload the document to the source record. All updates to the document will be done by the Submitter, the Document Manager, or an admin.

Approving, Requiring Changes for, and Rejecting Documents

The Approver can approve, require changes, or reject the document. If an Approver requires changes or rejects a document, they are required to provide Approval Notes.

  • Approving: When an approver clicks Approve, the Status of the approval is updated to Approved. Approval Notes are not required in order to approve. 

  • Requiring Changes: To mark a document as requiring changes, the approver must enter an explanation in the Approval Notes field. Any other approvers for the document are notified that a change is required, and so if they have already approved, they may need to re-approve once changes are complete. Another email to the Document Manager explains that a change has been requested, and the Document Manager will need to make changes and resend the document for approval.

  • Permanently Rejected: To mark a document as permanently rejected, the approver must enter an explanation in the Approval Notes field. Upon permanently rejecting, the Status of the approval is set to Permanently Rejected, and the Status of the document is set to Canceled. The document may not be resubmitted for approval. 

Publishing Documents

Once all approvals are completed, and the value of the field Total Number Still Awaiting Approval is 0, a rule sets the Status of the document to Ready for Publication. Both the Submitter and Document Manager are emailed that the document is ready for publication.

The Document Manager can then attach the final approved document to the Published Files field, and updates the Status to Published. A validation rule checks again to see if there are still any pending approvals. Once the Document is published, an email notification is sent to the Submitter.



In the standard system demo, the Documents table contains seven active rules. These rules are accessed by expanding the Documents table in the left pane, selecting Setup Documents, and then selecting the Rules tab:

  1. Edit: Refresh Concurrent Approvals if Total Number of Approvals Changes (web, API): This rule runs a saved search to fetch all records in which the total number of approvals changed in the last modification and then it refreshes the concurrent approvals using an update action.
  2. TB Demo Data Update: Update date fields by one month each month so reports have data: This rule runs a saved search to fetch demo records and then it updates their dates and deletes history entries for these records.
  3. All Edit Validations: This rule runs whenever a record is edited. It shows validation error if the status of a record is Pending Approval and no approvers have been assigned to it. It also shows validation error when the record is in the status of Published or Ready for Publication and approver has not been assigned to it.
  4. Edit: Last Approval Received (API Enabled): This rule fetches all the records in which the last approval has been received and then updates their status to Ready for Publication through an update action. It also sends an email to the Document management team and Submitter regarding the record's new status.
  5. Edit: All Edit Actions without API: This rule handles all major email notifications that are sent to the Document Management team and Submitter when the status of the record changes to Draft, Published, Pending document Manager or Ready for Publication. It runs a linked record action when Approver has been changed and then it updates Last Document Id field in the Employee record of the newly assigned approver. It also updates the status of associated Approval records to Pending Approval when the status of a document record changes to Pending approval and the Total number of required Reapprovals or Total number of Rejections is greater than or equal to 1.
  6. Create: All Creation Actions: This rule runs when a new document record is created. It runs an email action to notify the Document Management team when the status of a record is set as Pending Document Manager. If the source of the record is Service Request or Incident, this rule updates the Document Id and Document Status fields in its associated source's record through a linked field action.
  7. Edit: Handle Rejection of an approval (Web or API): This rule fetches records in which the Total number of rejections is greater or equal to 1 and status is not equal to Daft and, the Total number of rejections field changed in the last modification. Then, it updates their status as Draft and sends an email to Submitter stating that their document requires an update. Lastly, it runs a linked record action to set the Rejected field as Yes in linked approval records.


Document records are owned by the creator. Specifically, a record is owned by the user whose Login matches the Creator Login field.

  • No labels