Your Contract Management Data Template

Conga CLM
Your Contract Management Data Template

Your Contract Management Data Template

This template provides a clear roadmap for collecting the essential data needed to optimize your contract management process. It outlines the core attributes, critical activities to track, and includes helpful guidance for data extraction. By following these recommendations, you can efficiently prepare your data for comprehensive process analysis and uncover valuable insights.
  • Recommended attributes to collect
  • Key activities to track
  • Extraction guidance
New to event logs? Learn how to create a process mining event log.

Contract Management Attributes

These are the recommended data fields for your event log, crucial for comprehensive contract management analysis and identifying key performance indicators.
5 Required 6 Recommended 9 Optional
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 EventEndTime minus EventTimestamp. It is not stored in Conga CLM.

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
Required Recommended Optional

Contract Management Activities

These are the key process steps and milestones to capture in your event log for accurate process discovery and bottleneck identification.
7 Recommended 8 Optional
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
Recommended Optional

Extraction Guides

How to get your data from Conga CLM