Contract Requests Management
A contract request typically marks the beginning of the entire contract lifecycle process. It outlines the details for the contract, including the type of contract to create and the parties involved. The contract request includes all the activities necessary to initiate a new contract intake.
Administrators can use the to assign specific permissions to users for accessing the Manage Requests menu and the tabs, Incoming Requests, All Requests, and My Requests. This ensures that only authorized users can view and manage contract requests. For more information, see "Application Manager" in Administration Console.
Users with relevant permissions can raise contract requests. Users who initiate the request may or may not have access to the contracts after submission as it depends on roles and permissions. Once the request is submitted, it can be handled by a legal, procurement, or contracts team. For example, someone might request an NDA vendor agreement, but only the legal team has access to the final document or the negotiation stages.
Navigating to the Manage Requests menu
Manage Requests is a centralized feature within Contract Lifecycle Management (CLM) systems that enables users to initiate, track, and take action on contract-related requests. It serves as the starting point of the contract lifecycle by ensuring that requests are properly submitted, assigned, reviewed, and approved.
From the App Launcher, select Contract Apps and go to Manage Requests () on the left pane.
- Incoming Requests: Lists all requests that are pending approval. Additionally, approved contract requests that require contract manager intervention (i.e., not yet converted to contracts) are also displayed in Incoming Requests. This allows contract managers to review and take action on these requests directly.Note:
- Only contract managers can view approved-but-not-converted requests in Incoming Requests.
- Requests that are auto-approved and auto-converted are automatically removed from Incoming Requests, as they do not require manual intervention.
- After the contract manager approves a request, it moves to All Requests with the status retained as Approved, and a contract link is created upon successful processing.
- All Requests: Lists all requests that you have created as a requester, owned by you, approved, reviewed, or that have been shared or assigned to you.
- My Requests: Lists all contract requests where you are either the Creator (the user who submitted the request) or the Requester (the user on whose behalf the request was submitted). The listing page displays requests sorted by modified date.Note:
If a request is raised by another user on your behalf (for example, an admin or delegate), it appears in both your My Requests grid and the creator's grid, allowing both parties to track progress and take follow-up actions.
Visibility in the My Requests grid is governed by Role-Based Access Control (RBAC) and Policy-based Access Control (PBAC). Gaining visibility to a request as a Requester does not elevate user permissions or bypass org-level visibility rules. Users can only view details or perform actions (such as editing or withdrawing a request) that are explicitly allowed by their assigned role and permission set.
Bundled (Multiple) Contract Requests
Bundled (multiple) contract requests allows you to create and submit multiple contract requests together in a single wizard flow, rather than creating each one separately.
When you are creating a contract request, enable the Is Multiple Request toggle in the New Request window to bundle a primary contract request type with one or more related (child) request types and submit them together in a single flow.
The primary request type is the parent in the resulting parent–child contract hierarchy. The additional request types are children. The same contract type cannot be selected as both the primary and an additional type.
How bundled (multiple) contract requests work
-
Selecting the primary request type first determines which request types are available as additional types; the primary type is excluded from the additional types list.
-
As soon as you click Next on the initial form, a draft record is created in the system for each request type in the bundle.
-
Common fields (Account/Supplier, Request Name, Description, legal entity, start and end dates) are shared across all request types and pre-populated in each step. Changing a shared field in one step updates it in all steps.
-
Each request type has its own Request Form and Upload Documents step, accessible via the wizard's progress tabs. Click Next Page to advance to the next request type's form.
-
A Summary step at the end shows all selected request types, key fields, and uploaded documents. Use the Edit icon in the summary to make corrections before submitting.
-
Clicking Submit submits all requests in the bundle simultaneously. Each request then follows its own approval flow.
Draft and cancel behavior for bundled requests
-
Saving a bundle as draft saves all request types in Draft status. Reopening any record in the bundle shows the full multi-tab wizard view as long as all records in the bundle are still in Draft status.
-
If the records in a bundle have different statuses (for example, one is Pending Approval and another is Draft), the multi-tab wizard view is not shown. However, the View Related Requests button remains available on each record so you can see the full bundle status.
-
Cancelling a bundle in which all records are in Draft status cancels all records in the bundle. If only one record is in a later status (for example, Pending Approval), only that individual record is cancelled.
View Setting
View Setting in the classic UI allows you to control which columns are displayed in the grid and rearrange the column order. Click the View Settings () icon to control the columns displayed in the grid. For more information, see Custom View Settings.
You can save your filtered view of a record and set as the default view to avoid reselecting the filters every time you open the grid view (list view). For more information, see Custom Views.
Conversations
Conversations keeps all communication related to a contract request in one central location. You can post messages, reply to individual messages in context, attach supporting documents, and use @mentions to notify specific team members. All messages and attachments are stored directly in the contract request record, creating a persistent history of discussions and decisions made throughout the request lifecycle.
Access to Conversations is role-based. You can view and participate in conversations according to your assigned permissions.
Prerequisites: The administrator has enabled the following:
- Feature flag to enable the modern UI.
- Turned on the Conversation toggle in .
For more information, see Conversations.