...
- Record Type
- Internal Contract Owner
- Contract Type
- Days in advance to notify for renewal
- Contract Title
- Contract Description
- Contract Start Date
- Contract End Date
Use Case for Power Users
This section covers the use case for power users.
...
Creating Contracts
Contract records can be created by members of the Admin, Admin Import, Business Admin, Contract Creator, Contract Requester, Contract Manager, Contract Owner, Project Manager, and Sales groups. Contracts may be created in one of two ways:
...
See the Risk Conditions Table and Contract Risk Conditions Table articles for more detail.
Use Case for End Users
This section covers the use case for end users in a Contract Management context.
Members of the Contract Creator group are internal employees who access the system by way of the End User Interface (EUI). Contract creators, also called contract requesters, are users who submit requests for contracts, but do not work on or manage the contract once it is requested and submitted. Below is a representative home page for an end user in the Contract Creator group:
Creating Contracts
Users in the Contract Creator group can create contracts by:
...
Once the required information is filled in, the Contract record can be saved for later revisions. The contract requester can also press the Submit for Review button to request approval from a contract manager. Contract requesters can be contacted to update the submitted contract, but they are typically no longer involved in the approval process from this point forward. After the contract requester submits the contract for review, a contract manager decides whether to continue with the approval process or reject the contract request.
Working with Contracts
At any time, the contract requester can view contracts they previously submitted by:
...
The contract requester can view all contracts they have permission to see by clicking on the All Contracts home page link or tab.
Automation
Some of these rules have been mentioned or quickly described in the use cases above. In the Standard System Demo, the Contracts table contains twelve active rules. Most time-based rules, marked with a "TB," are disabled by default in the Standard System Demo. These rules are accessed by expanding the Contracts table in the left pane, selecting Setup Attachments, and then selecting the Contracts tab:
- Edit: Validate that end date is after start date (web): This rule ensures that when a Contract record is edited, the start date is before the end date. If this is not the case, a Validation action warning the user about this conflict is triggered.
- Edit: Update Renewal Notification Date if underlying fields change (web,api): This rule ensures that when a Contract record is edited, the Renewal Notification Date gets updated. This rule can update auto-renewing contracts or set a renewal notification date for non auto-renewing contracts. It also can set the Alert Color to red for Contract records that have a past Renewal Notification Date.
- TB: (DISABLED) Daily check for start date: This rule uses a saved search to check for Contract records that start on the present day, or earlier, with a Status of Signed, and changes their Status to Active. It also sets the Status of any previous contracts to Renewed.
- Edit: Handle Status Changes (rule should always be lowest priority): This rule runs any time a record's Status changes. It creates a new Status Time record and also updates the Previous Status field to reflect what the record's Status was before the change was made. This rule runs from edits made by users, rules, or emails.
- TB: (DISABLED) Notify of upcoming expirations: This rule sends emails to contract owners of records that have a renewal date of one day in the future, as long as those records can be renewed more than once. It runs every two days, early in the morning.
- Edit: Update Alert Color if Renewal Notification Date Changed (web, api): This rule ensures that a record's Alert Color is still accurate whenever a record's Renewal Notification Date is changed by either a user or another rule.
- Edit: Updates by Party: This rule ensures that if an outside party makes an update to a Contract record, the owner of the contract and the Contract Manager team are notified. It also creates an Attachment Type and a Title for any files that may have been added.
- Create/Edit: If Transitional Contract Files field has value, convert to Attachment: This rule runs on new Contract records, or records that have had their Transitional Contract Files field changed. It converts the newly added file to an Attachment record, and then clears the Transitional Contract Files field for future uploads.
- TB Demo Data Update: Update date fields by one month each month so reports have data: This time-based rule runs once every month, updates Demo Date fields, and deletes the History associated with the Demo Date fields being updated.
- Edit: Most edit actions by web or api: This rule runs whenever a Contract record is edited by a user or another rule, and ensures that all the data in the record remains unified and consistent with the current stage of the contract lifecycle.
- Create: All New Contract Actions: This rule runs whenever a Contract record is created by a user or another rule, and ensures that all the data in the record is unified and consistent with the beginning of the contract lifecycle. For example, some of the things this rule ensures are that the contract end date isn't before the contract start date, and that if the new Contract record is a renewed version of a previous Contract record, the records are linked.
- TB: (DISABLED) Daily check for expiration date: This rule runs daily on Active records with an End Date on the present day or before. It ensures that the renewable contracts get renewed and resets their end date. If contracts cannot be renewed, it sets their Status to Expired. Either way, the rule also notifies the contract owner of the End Date.
Workflow
The Contracts table has the following default workflow:
Ownership
Records in this table are owned by the Contract Requester. Specifically, a record is owned by the user whose ID matches the number in the Requester ID field. By default, the Contract Requester is the user who created the Contract record. For this reason, the owner of a Contract record is often an end user Requester, rather than a power user Internal Contract Owner, despite the field name.
Reports
The Contracts table contains the following default Charts and Reports:
...