Your Contract Management Data Template
Your Contract Management Data Template
- Recommended attributes to collect
- Key activities to track
- Extraction guidance
Contract Management Attributes
| Name | Description | ||
|---|---|---|---|
|
Activity Name
ActivityName
|
The name of the specific business event or task that occurred in the contract lifecycle. | ||
|
Description
The Activity Name describes a step or milestone within the contract management process, such as 'Contract Drafted', 'Legal Review Conducted', or 'Contract Executed/Signed'. This attribute is used to build the process map, showing the sequence of actions taken. Analysis of this attribute reveals the process flow, identifies common and alternative paths, and helps measure the frequency of each activity. It is fundamental for calculating KPIs related to process conformance, rework, and cycle times between different stages.
Why it matters
It defines the steps of the process, forming the backbone of the process map and enabling the analysis of workflow, deviations, and activity frequency.
Where to get
This is often derived by mapping status changes, completed tasks, or specific events logged against the Contract object in Conga CLM.
Examples
Contract DraftedLegal Review ConductedContract Executed/SignedContract Renewed
|
|||
|
Contract ID
ContractId
|
The unique identifier for each contract agreement, serving as the primary case identifier. | ||
|
Description
The Contract ID is the definitive case identifier that links all events and activities related to a single contract's lifecycle. It allows for the end-to-end tracking of a contract from its initial request through drafting, negotiation, execution, and eventual termination or renewal. In process mining analysis, every event must be associated with a Contract ID to reconstruct the journey of each contract. This enables a comprehensive view of the entire process, making it possible to analyze cycle times, identify bottlenecks, and monitor conformance for individual contracts or segments of contracts.
Why it matters
This is the essential key for tracing a contract's complete lifecycle, enabling all process mining analyses by connecting related activities into a single case.
Where to get
This is typically the primary key of the main Agreement or Contract object in Conga CLM, often named something like 'Apttus_Config2__AgreementId__c'.
Examples
a015g00000_12345a015g00000_67890a015g00000_ABCDE
|
|||
|
Event Timestamp
EventTimestamp
|
The precise date and time when the activity started or occurred. | ||
|
Description
The Event Timestamp records the moment a specific activity took place. It provides the chronological order needed to reconstruct the process flow for each contract. Timestamps are essential for all time-based process mining analysis. This attribute is used to calculate durations between activities, overall case cycle times, and waiting times. It is critical for identifying bottlenecks, monitoring SLA compliance, and understanding the temporal dynamics of the contract management process. It serves as the primary sorting key for events within a case.
Why it matters
It provides the chronological sequence of events, which is essential for calculating all duration-based metrics, discovering bottlenecks, and understanding process performance.
Where to get
This data is typically found in history tracking fields like 'CreatedDate' on related task or event objects, or specific date fields on the main Contract object.
Examples
2023-04-15T10:05:00Z2023-05-20T14:30:00Z2023-06-01T09:00:00Z
|
|||
|
Last Data Update
LastDataUpdateTimestamp
|
The timestamp indicating when the data for this record was last refreshed from the source system. | ||
|
Description
This attribute records the date and time of the most recent data extraction from Conga CLM. It is a critical piece of metadata for understanding the freshness of the analysis and ensuring that decisions are based on up-to-date information. In dashboards and reports, this timestamp informs users how current the data is. It is essential for data governance and for managing user expectations about the timeliness of the insights provided by the process mining tool.
Why it matters
This timestamp indicates the freshness of the data, ensuring that any analysis or decisions are based on an understood and acceptable timeframe.
Where to get
This is a metadata field typically generated and populated by the ETL (Extract, Transform, Load) tool or script during the data ingestion process.
Examples
2024-07-20T02:00:00Z2024-07-21T02:00:00Z
|
|||
|
Source System
SourceSystemName
|
Identifies the source system from which the data was extracted. | ||
|
Description
This attribute specifies the system of record for the event data, which in this case is Conga CLM. It is important for data governance and traceability, especially in environments where data may be merged from multiple systems. While it may seem static in a single-system analysis, it provides crucial context about data origin, helping to ensure data integrity and troubleshoot data extraction issues. It becomes vital when combining contract data with information from other systems like a CRM or ERP.
Why it matters
It provides essential context for data lineage and governance, ensuring clarity on where the process data originates, which is crucial for validation and trust.
Where to get
This is typically a static value added during the data extraction and transformation (ETL) process to label the dataset's origin.
Examples
Conga CLMCongaCLM-ProdSalesforce-CongaCLM
|
|||
|
Contract Owner
ContractOwner
|
The user or employee responsible for managing the contract through its lifecycle. | ||
|
Description
The Contract Owner is the individual assigned primary responsibility for a contract. This person is typically in charge of drafting, negotiation, and ensuring the contract moves forward through the approval process. Analyzing process performance by Contract Owner can reveal variations in efficiency, adherence to the standard process, and workload distribution. This helps in identifying best practices, training needs, and potential imbalances in resource allocation. It is a key dimension for performance and productivity analysis.
Why it matters
It allows for performance analysis by user, helping to identify top performers, training opportunities, and workload distribution issues.
Where to get
This is likely a user lookup field on the main Agreement object in Conga CLM, often named 'OwnerId' or a custom 'Contract_Owner__c' field.
Examples
Alice JohnsonRobert ChenMaria Garcia
|
|||
|
Contract Status
ContractStatus
|
The current lifecycle stage of the contract, such as 'Draft', 'In Approval', or 'Executed'. | ||
|
Description
Contract Status indicates the current state of a contract within its lifecycle. It provides a snapshot of where the contract is at any given moment, which is distinct from the event-based activity name. While the event log shows the sequence of past activities, the status provides context about the contract's current disposition. It's useful for filtering cases, for instance, to analyze only currently active contracts or to investigate why many contracts are stuck in the 'In Approval' status. It complements the activity data by providing state information.
Why it matters
It provides a snapshot of the contract's current stage, which is useful for filtering and analyzing active cases and understanding process state distributions.
Where to get
This is a standard picklist field on the Agreement object, often 'Apttus_Config2__Status__c' or 'Apttus_Config2__Status_Category__c'.
Examples
DraftIn Internal ReviewExecutedExpired
|
|||
|
Contract Type
ContractType
|
The classification of the contract, such as NDA, MSA, or SOW. | ||
|
Description
Contract Type is a categorical attribute that groups contracts based on their legal purpose or nature. Common examples include Non-Disclosure Agreement (NDA), Master Services Agreement (MSA), and Statement of Work (SOW). This dimension is fundamental for comparative analysis. It allows you to filter the process map to see if different types of contracts follow different paths or have different cycle times. This is essential for identifying process variations that are appropriate for certain contract types versus those that are true deviations.
Why it matters
It enables segmentation of the process to compare workflows, cycle times, and bottlenecks for different contract categories like NDAs versus MSAs.
Where to get
This is typically a picklist or lookup field on the Agreement object, often named 'Apttus_Config2__Contract_Type__c' or similar.
Examples
Non-Disclosure Agreement (NDA)Master Services Agreement (MSA)Statement of Work (SOW)
|
|||
|
Contract Value
ContractValue
|
The total monetary value associated with the contract. | ||
|
Description
Contract Value represents the financial worth of an agreement. This could be the total contract amount, annual recurring revenue, or another key financial metric depending on the business context. Analyzing this attribute is critical for value-based process optimization. It allows for the prioritization of high-value contracts and helps answer questions such as whether high-value contracts are processed faster or if they get stuck in certain stages more often. It is key for the 'Contract Value Throughput Analysis' dashboard.
Why it matters
This allows for value-based analysis, helping to prioritize process improvements for high-value contracts and understand their impact on the business.
Where to get
This is typically a currency field on the Agreement object in Conga CLM, such as 'Apttus_Config2__Total_Contract_Value__c'.
Examples
500002500001200000
|
|||
|
Event End Time
EventEndTime
|
The precise date and time when an activity was completed. | ||
|
Description
The Event End Time marks the completion of a specific task or process step. When paired with the Event Timestamp (start time), it allows for the precise calculation of the processing time for each activity. This attribute is crucial for performance analysis, enabling the measurement of how long each step takes. This helps in identifying which activities are the most time-consuming and offers a more accurate view of resource utilization and efficiency compared to just using the start time of the next event.
Why it matters
It enables the precise calculation of activity processing times, which is critical for identifying duration-based bottlenecks and analyzing resource efficiency.
Where to get
This timestamp can be found on fields like 'CompletedDate' or 'ActualEndDate' on task or activity objects related to the main contract.
Examples
2023-04-15T18:35:00Z2023-05-21T11:00:00Z2023-06-01T17:45:00Z
|
|||
|
Expiration Date
ExpirationDate
|
The date on which the contract is set to expire. | ||
|
Description
The Expiration Date is a critical date field that marks the end of a contract's term. It is essential for managing the contract lifecycle post-execution. This attribute is crucial for the 'Upcoming Renewals and Expirations' dashboard and the 'Timely Renewal Rate' KPI. By analyzing this date, organizations can proactively manage contract expirations, initiate renewal processes in a timely manner, and avoid unintentional lapses in service or revenue.
Why it matters
This date is critical for proactive contract management, enabling dashboards that track upcoming expirations to prevent missed renewals and revenue loss.
Where to get
This is a standard date field on the Agreement object, often 'Apttus_Config2__EndDate__c'.
Examples
2025-12-312026-06-302024-08-15
|
|||
|
Approval Cycle Time
ApprovalCycleTime
|
The total time a contract spends in the approval phase. | ||
|
Description
Approval Cycle Time is a calculated metric that measures the duration from when a contract enters the approval process, for example 'Internal Review Started', until it receives final internal approval. It aggregates the time across all relevant approval steps. This attribute is the primary measure for the 'Contract Approval Cycle Time' dashboard and the 'Average Contract Approval Time' KPI. It provides a high-level view of the efficiency of the entire approval workflow, making it easy to track performance against targets and identify systemic delays.
Why it matters
This KPI directly measures the efficiency of the approval workflow, helping to identify and address delays in a critical phase of the contract lifecycle.
Where to get
This is a calculated metric, derived by finding the time difference between the first approval activity and the final approval activity for each contract.
Examples
259200604800432000
|
|||
|
Business Unit
BusinessUnit
|
The specific business unit within the organization that the contract belongs to. | ||
|
Description
The Business Unit attribute assigns a contract to a specific division or segment of the company, such as 'Enterprise Software' or 'Consumer Hardware'. This allows for more granular analysis of the contract management process within different parts of the organization. Analyzing by Business Unit can show if different divisions have unique process variants, performance levels, or contract types. This is valuable for large organizations looking to standardize processes while accommodating valid business unit-specific needs.
Why it matters
It enables process performance to be segmented by organizational division, highlighting variations in efficiency or procedure across the company.
Where to get
This could be a custom field on the Agreement object or derived from the contract owner's user profile.
Examples
North America SalesEMEA ServicesAPAC Product Division
|
|||
|
Compliance Status
ComplianceStatus
|
Indicates whether the contract has passed necessary compliance reviews. | ||
|
Description
Compliance Status tracks the state of a contract with respect to internal policies or external regulations. It may have values like 'Not Started', 'In Review', 'Passed', or 'Failed'. This attribute is essential for the 'Compliance and Obligation Monitoring' dashboard and the associated KPI. It provides direct visibility into compliance adherence, helping to mitigate legal and financial risks by ensuring that all contracts undergo and pass the required checks before execution or activation.
Why it matters
It directly measures adherence to compliance protocols, helping to identify and mitigate legal and financial risks within the contract portfolio.
Where to get
This is likely a custom picklist field on the Agreement object, updated by specific compliance-related activities or approvals.
Examples
PassedNeeds ReviewNot ApplicableFailed
|
|||
|
Counterparty Name
CounterpartyName
|
The name of the external party, company, or individual involved in the contract. | ||
|
Description
Counterparty Name identifies the other signatory to the agreement. This is typically a customer, vendor, or partner organization. Analyzing process metrics by counterparty can reveal important patterns. For example, it might show that negotiations with certain counterparties consistently take longer or require more revisions. This insight can inform negotiation strategies and help in managing relationships with key business partners.
Why it matters
It enables analysis of process variations based on the external party, helping to identify which customers or vendors have longer negotiation cycles or higher revision rates.
Where to get
This is often a lookup to the Account object in Salesforce, which is linked to the Agreement object in Conga CLM.
Examples
Global Tech Inc.Innovate Solutions LLCAcme Corporation
|
|||
|
Is Rework
IsRework
|
A calculated flag that indicates if an activity is part of a rework loop. | ||
|
Description
Is Rework is a boolean flag that is set to 'true' if an activity represents a step back in the process, such as returning to the 'Contract Drafted' stage after a legal review. It is not a field in the source system but is calculated during data transformation for process mining. This flag is invaluable for quantifying process inefficiency. It directly supports the 'Contract Rework Rate' KPI and helps visualize process loops in the process map. Identifying the frequency and causes of rework is a primary goal of many process improvement initiatives.
Why it matters
This calculated flag makes it easy to quantify and analyze process inefficiencies by highlighting activities that are part of wasteful rework loops.
Where to get
This attribute is not in the source system. It is calculated in the process mining tool or ETL layer based on the sequence of activities.
Examples
truefalse
|
|||
|
Owner Department
OwnerDepartment
|
The department of the contract owner, such as 'Sales', 'Legal', or 'Procurement'. | ||
|
Description
The Owner Department attribute specifies the business function to which the contract owner belongs. This information is typically derived from the user's profile in the system. This is a powerful dimension for analysis, allowing for comparisons of process performance across different departments. It can help identify if the Legal department is a bottleneck, if the Sales team follows a different process, or if certain departments have significantly longer cycle times. This insight is valuable for cross-functional process improvement initiatives.
Why it matters
It allows for process analysis by business function, revealing performance differences and bottlenecks between departments like Sales and Legal.
Where to get
This data is usually pulled from the User object in Salesforce, linked via the Contract Owner field on the Agreement object.
Examples
SalesLegalProcurementFinance
|
|||
|
Processing Time
ProcessingTime
|
The calculated duration of time spent actively working on an activity. | ||
|
Description
Processing Time measures the time elapsed between the start and end of an activity. It represents the actual work duration, as opposed to waiting time between activities. This metric is computed using the Event Timestamp and Event End Time. This attribute is essential for identifying which specific steps in the process are the most time-consuming. It supports the 'Review Phase Bottlenecks' dashboard by allowing a detailed analysis of activity durations. Differentiating between processing time and waiting time is key to understanding the root causes of delays.
Why it matters
It measures the active work time for each activity, helping to distinguish between inefficient steps (long processing time) and process delays (long waiting time).
Where to get
This is a calculated attribute, derived from
Examples
864001728003600
|
|||
|
Region
Region
|
The geographical region associated with the contract, such as 'North America' or 'EMEA'. | ||
|
Description
The Region attribute indicates the geographic area relevant to the contract, which could be based on the counterparty's location, the sales region, or the governing law. This attribute allows for geopolitical analysis of the contract process. It can help answer questions like, 'Do contracts in EMEA take longer to approve due to different regulations?' or 'Is there a higher rate of redlining for contracts in the APAC region?' This provides valuable context for global operations.
Why it matters
Segmenting by region helps identify geographic variations in cycle times, compliance requirements, or process paths, which is key for global businesses.
Where to get
This is often a custom field on the Agreement object or derived from the linked Account or User objects.
Examples
North AmericaEMEAAPACLATAM
|
|||
|
Renewal Date
RenewalDate
|
The target date for initiating the renewal process for the contract. | ||
|
Description
The Renewal Date is a calculated or manually set date that indicates when the renewal process for a contract should begin. It is typically set some period, for example 90 days, before the Expiration Date. This attribute helps teams manage their renewal pipeline effectively. It can be used to trigger alerts and automate tasks related to contract renewals, ensuring that the process starts with enough lead time. It is a key element for the 'Timely Renewal Rate' KPI.
Why it matters
It provides a trigger point for renewal activities, helping to ensure contracts are renewed on time and supporting proactive lifecycle management.
Where to get
This may be a custom formula field based on the Expiration Date or a separate date field on the Agreement object in Conga CLM.
Examples
2025-10-022026-04-012024-05-17
|
|||
Contract Management Activities
| Activity | Description | ||
|---|---|---|---|
|
Contract Activated
|
Represents the contract becoming effective and operational within the organization, triggering obligations and entitlements. This is typically inferred from a status change from 'Executed' to 'Active'. | ||
|
Why it matters
This activity marks the beginning of the post-signature lifecycle. It is the trigger for obligation management and performance monitoring.
Where to get
Inferred from the Contract object's status field history. The event is the timestamp when the status changes to 'Active' or an equivalent term.
Capture
Identify timestamp of status change from 'Executed' to 'Active'.
Event type
inferred
|
|||
|
Contract Executed/Signed
|
This is the pivotal activity where all parties have legally signed the contract, making it a binding agreement. E-signature solutions integrated with Conga CLM, like Conga Sign, create an explicit, timestamped event. | ||
|
Why it matters
This activity represents the successful completion of the pre-signature process and is a key milestone for performance metrics like 'Contract Execution Rate'. It is often considered the primary 'happy path' end event.
Where to get
Captured from the audit trail or status of the integrated e-signature tool. A final 'Completed' or 'Signed' status is recorded with a precise timestamp.
Capture
Log the completion event from the integrated e-signature service API or status object.
Event type
explicit
|
|||
|
Contract Expired
|
Represents the natural end of a contract's lifecycle when it reaches its expiration date without renewal or termination. This event is not explicitly logged but is derived from the contract's data. | ||
|
Why it matters
This activity defines the planned end of the contract lifecycle. Analyzing expired contracts helps in understanding renewal opportunities and overall contract portfolio management.
Where to get
This is a calculated event. The activity occurs when the system date surpasses the 'Contract End Date' or 'Expiration Date' field on the Contract object, and its status is still 'Active'.
Capture
Derive by comparing the 'Contract End Date' field with the current date.
Event type
calculated
|
|||
|
Contract Request Initiated
|
This activity marks the formal beginning of the contract lifecycle, representing the creation of a new contract record in the system. This is typically captured as an explicit event when a user creates a new Contract object in Conga CLM. | ||
|
Why it matters
As the starting point for every contract, this activity is essential for measuring the end-to-end cycle time. It allows for analysis of the volume and types of contracts being initiated.
Where to get
This event is captured from the creation date and timestamp of the Contract record in the Salesforce platform, on which Conga CLM is built. The user who created the record is also typically logged.
Capture
Track the creation event of the primary Contract object.
Event type
explicit
|
|||
|
Contract Terminated
|
This activity marks the premature end of a contract before its expiration date, based on a specific action. This is captured by a change in the contract's status to 'Terminated'. | ||
|
Why it matters
As a key end state, termination events are important for understanding contract failure rates and reasons for cancellation. It provides a definitive, albeit often negative, conclusion to the process.
Where to get
Inferred from the Contract object's status field history. The event is the timestamp when the status is updated to 'Terminated' or 'Cancelled'.
Capture
Capture timestamp of status change to 'Terminated'.
Event type
inferred
|
|||
|
Internal Approvals Obtained
|
This milestone signifies that the contract has received all necessary internal approvals and is ready for execution. This is typically the final step in a multi-stage Salesforce Approval Process. | ||
|
Why it matters
This is a critical milestone that concludes the internal review and approval cycle. It is the endpoint for measuring the 'Average Contract Approval Time' KPI.
Where to get
Captured from the Salesforce Approval History related list on the Contract object. The event is the timestamp of the final 'Approved' status in the process.
Capture
Capture timestamp of the final approval step in the associated approval process.
Event type
explicit
|
|||
|
Legal Review Conducted
|
This activity signifies that the legal department has completed its review of the contract. It can be captured either as an explicit approval step in a workflow or inferred from a status change like 'Legal Review Complete'. | ||
|
Why it matters
Isolating the legal review phase is crucial for analyzing a common bottleneck. This supports the 'Average Legal Review Time' KPI and helps in optimizing legal department resources.
Where to get
This can be logged in the approval history related list if using Salesforce Approvals. Alternatively, it can be inferred from a status change on the Contract object.
Capture
Capture timestamp of status change to 'Legal Review Complete' or the final approval step from the legal queue.
Event type
inferred
|
|||
|
Amendment Requested
|
Indicates the start of a process to formally change an existing, active contract. This is typically captured by the creation of a new 'Amendment' record that is related to the original contract. | ||
|
Why it matters
Amendments represent significant process variations. Analyzing their frequency and cycle time can reveal issues with original contract scoping or changing business needs.
Where to get
Captured from the creation date of a new record on an 'Amendment' or similarly named object that has a lookup relationship to the primary Contract object.
Capture
Track the creation event of an 'Amendment' record linked to the contract.
Event type
explicit
|
|||
|
Compliance Review Performed
|
A post-activation activity where the contract is reviewed against compliance requirements or regulations. This may be captured when a related task or checklist item is marked as complete. | ||
|
Why it matters
This activity is crucial for monitoring governance and risk management. It supports the 'Compliance Review Adherence Rate' KPI by tracking if and when these checks occur.
Where to get
Likely inferred from the completion of a related Task or custom 'Compliance Review' object linked to the Contract. The completion date of this record serves as the event timestamp.
Capture
Capture the completion date of a recurring task or related compliance record.
Event type
inferred
|
|||
|
Contract Drafted
|
Represents the completion of the initial contract document authoring. This is often inferred from a status change on the contract record, for example, from 'Requested' to 'Drafting' or 'In Review'. | ||
|
Why it matters
Tracking this activity helps measure the time spent on initial drafting. Delays here can indicate issues with templates, data gathering, or resource allocation.
Where to get
Inferred from the Contract object's status field history. Look for a timestamp when the status changes to a post-drafting value like 'Internal Review'.
Capture
Identify status change from 'Draft' to the next logical state in the workflow.
Event type
inferred
|
|||
|
Contract Redlined/Revised
|
This activity occurs each time a new version of the contract document is checked in or uploaded during negotiations. Conga CLM's version control capabilities create a record for each document version. | ||
|
Why it matters
Tracking the frequency of redlines helps quantify the negotiation intensity and supports the 'Redline Iteration Count' KPI. It can highlight overly complex contracts or difficult negotiations.
Where to get
Captured from the version history of the contract document stored in Conga CLM. Each new version created after sending to the counterparty is a distinct event.
Capture
Log an event for each new document version created with a major version number change.
Event type
explicit
|
|||
|
Contract Renewed
|
Represents the successful renewal of a contract, extending its lifecycle. This can be captured by a status change on the original contract or the creation of a new contract record designated as a renewal. | ||
|
Why it matters
Tracking renewals is vital for revenue retention and business continuity, supporting the 'Timely Renewal Rate' KPI. It signifies a positive outcome for the contract lifecycle.
Where to get
Can be inferred from a status change to 'Renewed'. Alternatively, if a new contract record is created, the creation of this new record where 'Renewal For' field points to the old contract.
Capture
Identify status change to 'Renewed' or creation of a new, linked contract record.
Event type
inferred
|
|||
|
Contract Sent To Counterparty
|
Represents the explicit action of sending the contract document to the external party for their review and negotiation. Conga CLM often provides a specific 'Send for Negotiation' action that is logged. | ||
|
Why it matters
This activity marks the transition from internal processes to external negotiation. It is the starting point for measuring the negotiation cycle time.
Where to get
Typically captured as a logged Activity or Task record associated with the Contract, often created automatically by a system action.
Capture
Identify the 'Send for Negotiation' or 'Send to Counterparty' event log.
Event type
explicit
|
|||
|
Counterparty Approval Received
|
Indicates that the external party has agreed to the terms and is ready to sign. This is often a manually updated status or could be captured from a portal if used. | ||
|
Why it matters
This marks the end of the active negotiation phase. It is a key event for measuring the 'Average Negotiation Cycle Time' and predicting when a contract will be executed.
Where to get
Most likely inferred from a status change on the Contract object, such as moving to 'Awaiting Signature'. This is updated manually by the contract owner.
Capture
Capture timestamp when status is changed to 'Approved by Counterparty' or 'Pending Signature'.
Event type
inferred
|
|||
|
Internal Review Started
|
Marks the point when the drafted contract is submitted for review by internal stakeholders, such as finance or business unit managers. This is typically inferred from a status change to 'In Internal Review' or similar. | ||
|
Why it matters
This activity is the starting point for measuring the internal review cycle time. It helps identify how long contracts wait for review and how much time the review process itself takes.
Where to get
Inferred from the Contract object's status field history. The event is timestamped when the status changes to reflect the start of the internal review phase.
Capture
Capture timestamp when contract status changes to 'Internal Review' or equivalent.
Event type
inferred
|
|||