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, Sourcing Event, 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, Sourcing Events, 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.

When generated from Sourcing Event records, an approval can be in either of these two states:

• Pre-Approval, such as you would see from an Initial Sourcing Event.
• Final Approval, such as you would see for Selection Approvals. When in a Final Approval state, the Approval record includes an embedded search under the Solicitation heading of the Details tab. This search lists any supplier responses related to the Sourcing Event that have been accepted, and thus have a Status of Awards Recommended. This allows the approver to see any successful supplier responses for the sourcing event.

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:

• Clicking Create Approvals in the Approvals tab of a Contract record
• Clicking New in the action bar of the Approval Needed section in the Approvals tab of a Contract record
• Manually, from the Approvals table

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.

In a Contract Approval Workflow, one may also include Reviews and Notifications. Reviews do not allow the assigned reviewers to reject the Contract. However, reviewers may still provide feedback the same way an approver would. Notifications inform the assigned users via an email, without requiring any action on their part.

Use Case for Document Approvals

Document Approval records can be created in two ways:

• Clicking Submit for Approval from the Details tab of a Document record
• Manually, from the Approvals table

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 Documents Table section.

Use Case for Sourcing Event Approvals

Sourcing Event Approval records can be created in two ways:

• Clicking Create Approvals in the Selection Process tab of a Sourcing Event record
• Manually, from the Approvals table

Generally, the best option is to create an Approval directly from the Sourcing Event 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 Sourcing Event 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 Sourcing Event Type by checking the Available for Sourcing Event Types field of the Approval Workflow record. The default workflow by Sourcing Event Type can be set within the Sourcing Event Type table.

Use Case for Change Request Approvals

Change Request Approval records can be created in two ways:

• Clicking Generate Approvals in the Approvals tab of a Change Request record
• Manually, from the Approvals table

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.

Automation

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):

• Create: All Change Approval Creation Actions (web, API): This rule runs whenever a new Approval record is created for a Change Request record by a user or by another rule in the system. It consist of two If-Then-Else actions called I: Change Request Creation Actions and I: Assign Actions. I: Change Request Creation Actions automatically sets the values for Next Step Number, Concurrent Approvals, Lowest Step Number, and Next Approvals using Update Actions. These Update Actions contain saved searches that use global variables to ensure the values being used to populate the aforementioned fields are accurate. I: Assign Actions sets the value for Approval Team if the Approval Team field is left blank.
• Edit: All Change Approval Edit Actions (web, API): This rule runs whenever an Approval record for a Change Request record is edited by a user or by another rule in the system. It consists of a single If-Then-Else action called I: All Change Approval Edit Actions. This action ensures that when the record is edited, Approval Notes are copied to the parent record, and the values of the record are properly set. It can also send emails to Approvers.
• Create: All Document Approval Creation Actions (web, API): This rule runs whenever a new Approval record is created for a Document record by a user or by another rule in the system. It consists of a single If-Then-Else action that works more like a repository for four Update actions and an Email action. Similar to Create: All Change Approval Creation Actions (web, API), the Update Actions contain saved searches that use global variables to ensure the values being used to populate the Related To, Approval Team, Status, Concurrent Approvals, and Approval Title fields of the Document Approval record are accurate.
• Edit: All Document Approval Edit Actions (web, API): This rule runs whenever an Approval record for a Document record is edited by a user or by another rule in the system. It consists of a single If-Then-Else action called I: All Document Approval Edit Actions, which ensures that when the record is edited, Approval Notes are copied to the parent record, and the proper people get emailed if the Status changes.
• Create: All Contract Approval Create Actions (web, API): This rule runs whenever a new Approval record is created for a Contract record by a user or by another rule in the system. It consists of two If-Then-Else actions called I: Contract Approval Creation Actions and I: Set Approval Team to Contract Assigned Team if empty. I: Contract Approval Creation Actions automatically sets the values for Related To, Contract Title, zApproval Packet Files, Next Step Number, Concurrent Approvals, and Next Approvals. It also sets Approver ID or Approval Team, based on the value in the Assign Approval Based On field. I: Set Approval Team to Contract Assigned Team if empty sets the Approval Team if the Approval Team or Approver fields are blank.
• Edit: All Contract Approval Edit Actions (web, API): This rule runs whenever an Approval record for a Document record is edited by a user or by another rule in the system. It consists of a single If-Then-Else action called I: All Contract Approval Edit Actions. This action ensures that when the record is edited, Approval Notes are copied to the parent record, and the values of the record are properly set. It can also send emails to Approvers.
• Create: Notify if Needed for Contract Approvals (web, API): This rule runs whenever a new Approval record is created for a Contract record by a user or by another rule in the system. Because of the saved search, this rule only runs if the new record is created a valid Contract ID and a Status of Pending Approval. It contains an If-Then-Else action called Handle Approvals created in Pending Approval Status, which emails stakeholders about approving Contract records when necessary.
• Edit: Approval by Email (web): This rule runs whenever an Approval record for a Contract record is edited by a user. Because of the saved search, this rule only runs if the new record's Approved by Email field has just been changed to Yes, and if the Status is Pending Approval. It consists of two Update Actions called U: Set Approved by Email to No and U: Set Status to Approved, which are self-explanatory.
• Create/Edit: Set Due Date to Working Day (web, API): This rule runs on approvals where the status is Pending Approval whenever a new Approval record is created or edited for a Contract record by a user or by another rule in the system. The logic sets the Due Date to the date the approval changed to Pending Approval + 2 business days.

Ownership 

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.