Approval records are a tangible instance of something that is usually considered intangible: an approval. Approval records consist mostly of information that belongs to other records. An Approval record allows you to keep track of things when the parent record, such as a Contract or Change Request record, requires approval by a stakeholder or manager. The Approvals table holds a physical instance of, for example, a contract approval that needs to, or has been, sent to a signing or reviewing party.

Each record in the Approvals table is an individual instance that is linked to a parent Change Request, Service Request, Purchase Request, Document, Project, Contract, Opportunity, Contact, Support Case, or Asset record. You can tell which table an Approval record is related to by checking the Related To field. In the Standard System Demo, there are currently only Approval records for Contracts, Documents, and Change Requests present.

Notably, each Approval record has a field for the Approval Team, the Approver, Approval Notes, the ID of the parent record, and others. On the History tab, there are fields that capture and display timestamps that relate to when the approvals occurred.

Approval records are usually generated by the Contract Manager from the record that requires approval using Approval Workflows and their related Approval Templates, but can also be created ad hoc from the parent record by users with the appropriate privileges. After the Approval records have been created, they will sit in a status of Queued until the approvals are launched. When the status is changed to Pending Approval, the Approver or a member of the Approval Team can add notes about the approval or rejection in the Approval Notes field. Notes added to the Approval Notes field of Approval records are appended to the Approval Notes field under the Approvals tab of the parent record.

Use Cases

Read the following use cases to learn more about how to create related Approval records from the Contract, Document, and Change Request tables.

Use Case for Contract Approvals

Contract Approval records can be created in three ways:

Generally, the best option is to create an Approval directly from the Contract record by clicking Create Approvals. However, before you can click Create Approvals, you must first select an Approval Workflow from the Workflow Title field in the Approvals tab. The Approval Workflows that are available to Contract records can be checked by looking at the Related To column of records in the Approval Workflow table. Remember to ensure that your Approval Workflow record is available for the correct Contract Type by checking the Available for Contract Types field of the Approval Workflow record. The default workflow by Contract Type can be set within the Contract Type table.

Users who click Permanently Rejected or Require Changes must enter Approval Notes explaining the decision. When the record is saved, the Approval Notes are appended to the All Contract Approval Notes field and are visible from any Approval record linked to that Contract. For more information on approvals for Contracts, see the Contract Management Table section.

Use Case for Document Approvals

Document Approval records can be created in two ways:

Generally, the best option is to create an Approval directly from the Document record by selecting Yes for the Requires Approval field from the Progress tab of a Document record. Then, choose the necessary Approvers, and click Submit for Approval to generate the Document Approval record.

The default Status for a new Document approval record is Pending Approval. Document Approval records are all created with a Step Number of one through conversion.  For more information on approvals for documents, see the Document Management Table section.

Use Case for Change Request Approvals

Change Request Approval records can be created in two ways:

The default status for a new Change Request approval record is Queued. 

Create and Launch Approvals

Clicking Create Approvals generates all of the Approval records needed for the selected workflow. If an approval template's Approval Usage field has a value of Conditional, then it is not created unless the condition is met.

The approvers are not notified until the Contract or Change Manager launches the approval process by clicking the Launch Approvals button. At that point, the Approval record with the lowest number is updated to Pending Approval and the approver is notified that the approval is due. If there is no value in the Approver field, the approver team is notified. If there are any concurrent approvals for a particular step, the Approval record is updated with those concurrent approvals.

If an approval step is marked as Auto-Approved, the Approval is updated to Approved and the approver or the Approval Team is notified of the auto-approval, unless the Notify for Auto-Approval field has a No value. This is a method of notifying someone about a Contract or Change Request without requiring them to respond.

The approver can approve the change by email through an Approval hotlink, but can also click the ‘Require Change or Reject’ hotlink. After clicking the ‘Require Change or Reject’ hotlink, the user can enter their comments, and then click either the Require Change button or Reject button. When editing the Approval record directly, comments are required if the Approval record is Rejected or marked as Require Changes.

A validation rule requires that any individual who clicks one of the three buttons to Approve, Reject or Require Changes is a member of the Approval Team.

Whenever the Approval Notes field is updated, a rule copies the update into the linked Contract or Change Request's All Approval Notes append only field, and the original Approval Notes field gets blanked out.

If the approver marks the approval as Require Changes, the linked Contract or Change Request is not changed, but the Contract or Change Management team and Contract or Change Manager are notified. They decide whether any changes require restarting the whole approval process, or can continue onward after revising the rejected approval. If they want to start over, they click the Relaunch Approvals button which sets all linked approvals to Queued and then relaunches the first step. Otherwise, they can set Require Changes back to Pending Approval for the process to continue without restarting.

If the approval is marked Approved and there are no concurrent approvals, the next Approval record in the sequence is updated to Pending Approval and the Approver or Approval Team are notified. If there are concurrent approvals, they all must be completed prior to the next approval step being updated to Pending Approval. The approver and the date approved are updated to reflect whoever clicked the Approve button.

If the approver marks the approval as Permanently Rejected, the linked Contract or Change Request is updated to a status of Rejected and the Requester and Contract or Change Management Team are notified. The user is required to resubmit the Contract or Change Request if it still required, albeit with the appropriate changes. All other approvals in the Contract or Change Request in a status of Queued or Pending Approval are updated to Not Needed. If an approval is updated from a status of Pending Approval to Not Needed as a result of a related approval's Permanently Rejected status, the Approver or Approval Team are notified that their approval is no longer necessary.


In the standard system demo, the Approvals table contains eight rules. These rules are accessed by expanding the Approvals table in the left pane, selecting Setup Approvals, and then selecting the Rules tab. They are listed based on approval type (Change Request, Document, Contract, other):


Approval records and Approval Template records are owned by the user who creates them. Specifically, a record is owned by the user whose Login matches the Creator Login field.