Your Claims Processing Data Template
Your Claims Processing Data Template
- Recommended attributes to collect
- Key activities to track
- Extraction guidance for Guidewire ClaimCenter
Claims Processing Attributes
| Name | Description | ||
|---|---|---|---|
| Activity Name ActivityName | The name of the business activity or event that occurred at a specific point in the claim lifecycle. | ||
| Description This attribute describes a specific step or milestone in the claims process, such as 'Claim Created', 'Investigation Started', or 'Payment Issued'. The sequence of these activities for a given Claim ID forms the process flow. Analyzing the sequence, frequency, and duration between activities is the core of process mining. It allows for the discovery of process models, identification of bottlenecks, detection of rework loops, and analysis of process deviations. Why it matters It defines the steps of the process, enabling the visualization of process maps and the analysis of process flow and bottlenecks. Where to get This is typically derived from event tables or audit logs in ClaimCenter, often by mapping specific system events or status changes to standardized activity names. Examples Claim CreatedLiability Decision MadePayment IssuedClaim Closed | |||
| Claim ID ClaimID | The unique identifier for each insurance claim, serving as the primary case identifier. | ||
| Description The Claim ID is the cornerstone of claims process analysis, uniquely identifying each case from submission to closure. It links all associated activities, documents, payments, and communications, ensuring a complete and coherent view of a claim's lifecycle. In process mining, every event in the dataset is tied to a Claim ID, allowing for the reconstruction of the end-to-end process flow. This is essential for analyzing cycle times, identifying process variants, and tracking a claim's journey across different departments and adjusters. Why it matters It is the fundamental key that connects all related events, making it possible to trace and analyze the entire journey of a single claim. Where to get This is a primary key in Guidewire ClaimCenter, typically found as Claim.ClaimNumber or a similar field in the core Claim entity. Examples 000-123-45678000-987-65432001-456-11223 | |||
| Event Time EventTime | The precise date and time when the activity occurred. | ||
| Description This timestamp marks the exact moment an activity was recorded in the system. It is fundamental for all time-based process analysis. The chronological ordering of EventTime for a single Claim ID allows for the reconstruction of the process flow. The time difference between consecutive events is used to calculate cycle times, waiting times, and processing times, which are critical for performance analysis, bottleneck identification, and SLA monitoring. Why it matters This timestamp is essential for ordering events, calculating cycle times and durations, and identifying delays in the process. Where to get Found alongside event or activity data in Guidewire ClaimCenter's history or audit tables, often as a 'CreateTime' or 'UpdateTime' field. Examples 2023-05-15T09:00:00Z2023-05-16T14:30:15Z2023-06-01T11:20:00Z | |||
| Assigned Adjuster AssignedAdjuster | The name or ID of the user assigned to handle the claim or a specific activity. | ||
| Description This attribute identifies the individual claims adjuster responsible for a claim at a given point in time. An adjuster may be assigned to the entire claim or to specific tasks within it. Analyzing by Assigned Adjuster is critical for workload balancing, performance management, and identifying training opportunities. It helps answer questions like: 'Which adjusters have the highest caseload?', 'Are there performance variations between adjusters?', and 'Is work distributed evenly?'. Why it matters Tracks user involvement, enabling workload analysis, performance comparison, and identification of resource-related bottlenecks. Where to get Available in the Claim or Exposure entity in ClaimCenter, often linked to the User object (e.g., Claim.Assignee). Examples j.doem.smiths.jones | |||
| Cause of Loss LossCause | The specific reason or cause of the loss event (e.g., Collision, Fire, Water Damage). | ||
| Description This attribute provides detailed context on why the claim was filed. The cause of loss often dictates the required investigation steps, the type of experts needed, and the overall complexity of the claim. Analyzing the process by Cause of Loss can reveal hidden patterns. For instance, claims related to 'Water Damage' might have a higher rate of rework or require more specialist involvement compared to 'Theft' claims. These insights help in creating more specialized and efficient handling procedures. Why it matters Provides context on the claim's nature, enabling analysis of how different loss causes impact process flow and duration. Where to get This is a standard field on the Claim entity, typically called 'LossCause'. Examples CollisionFireWater DamageTheft | |||
| Claim Status ClaimStatus | The overall status of the claim at the time of the event (e.g., Open, Closed, Denied). | ||
| Description This attribute reflects the high-level state of the claim. Key statuses include 'Open', 'Closed', 'Denied', and 'Reopened'. The final status of a claim is a critical outcome metric. Tracking changes in Claim Status helps define key process milestones and outcomes. It is used to identify the final resolution of a claim, calculate rejection rates, and analyze the frequency of claims being reopened after closure, which often indicates process issues or customer dissatisfaction. Why it matters Indicates the outcome of a claim, which is essential for analyzing rejection rates, closure patterns, and claim reopening frequencies. Where to get This is a core field on the Claim entity, typically named 'State' or 'Status'. Examples OpenClosedDeniedReopened | |||
| Claim Type ClaimType | The category of the insurance claim, such as Auto, Property, or Liability. | ||
| Description Claim Type is a fundamental categorization of a claim based on the line of business or the nature of the loss. Different claim types often follow distinct processes, have different complexity levels, and are subject to different regulations. Segmenting the process analysis by Claim Type is essential for meaningful insights. It allows for comparing process performance across different lines of business, identifying type-specific bottlenecks, and tailoring process improvement initiatives to the unique characteristics of each claim category. Why it matters Allows for segmentation of claims, as different types (e.g., Auto vs. Property) often follow different processes and have different performance targets. Where to get Derived from the Policy or Claim entity in ClaimCenter, often based on the Line of Business (LOB) code. Examples Personal AutoCommercial PropertyGeneral LiabilityWorkers Compensation | |||
| Claimed Amount ClaimedAmount | The total monetary amount initially claimed by the policyholder. | ||
| Description This attribute represents the value of the loss as reported by the claimant. It is often an initial estimate that may change as the claim is investigated and reserves are set. Analyzing the Claimed Amount helps in segmenting claims by financial impact. High-value claims often follow a more rigorous, complex process than low-value ones. Comparing the process for different value bands can reveal opportunities to streamline handling for smaller claims or apply more stringent controls for larger ones. Why it matters Allows for segmenting claims by financial value, as high-value claims may follow different, more complex processes. Where to get This information might not be a single field but could be derived from the initial loss estimates recorded on exposures. Examples 5000.00150000.00750.50 | |||
| Date of Loss LossDate | The date on which the incident or loss that triggered the claim occurred. | ||
| Description The Date of Loss is the date of the actual event (e.g., car accident, property damage) for which the claim is being made. This is distinct from the date the claim was reported or created. The time lag between the Date of Loss and the 'Claim Created' activity (known as reporting lag) is an important KPI. Analyzing this can provide insights into customer behavior and the effectiveness of first notice of loss channels. Why it matters Provides crucial context about the claim's origin and helps analyze reporting lag (time from incident to claim submission). Where to get This is a fundamental date field on the Claim entity, often named 'LossDate'. Examples 2023-05-102023-04-202023-05-28 | |||
| Department Department | The business unit or department responsible for handling the claim activity. | ||
| Description This attribute indicates the department or team to which the assigned adjuster belongs, such as 'Auto Claims', 'Property Claims', or 'Special Investigations Unit'. It provides an organizational context for the process. Analyzing by Department is crucial for understanding process performance at an organizational level. It helps identify inter-departmental hand-off delays, compare efficiency between teams, and allocate resources more effectively across the claims organization. Why it matters Provides organizational context, allowing for performance analysis across different teams and highlighting inter-departmental hand-off issues. Where to get This information is typically associated with the assigned user's or group's profile within ClaimCenter. Examples Auto Claims DivisionProperty Claims UnitSpecial Investigations Unit (SIU) | |||
| End Time EndTime | The timestamp indicating when an activity was completed. | ||
| Description The End Time marks the completion of an activity, especially for tasks that have a measurable duration, like 'Investigation' or 'Document Review'. While many process mining activities are instantaneous (StartTime is sufficient), activities with a distinct start and end are better represented with both timestamps. This attribute allows for the precise calculation of activity processing time, distinct from waiting time. It helps in identifying which specific tasks are time-consuming, rather than just observing long delays between different steps. Why it matters It enables the precise measurement of how long an activity takes to complete, separating processing time from waiting time. Where to get This may need to be derived by finding a subsequent event that logically concludes the activity (e.g., status change from 'In Progress' to 'Completed'). Examples 2023-05-15T17:00:00Z2023-05-16T15:00:00Z2023-06-02T10:00:00Z | |||
| Is Automated IsAutomated | A flag indicating whether an activity was performed automatically by the system or by a human user. | ||
| Description This boolean attribute distinguishes between activities executed by a system (e.g., automatic reserve creation, system-generated correspondence) and those performed manually by an adjuster. Analyzing this attribute is key to understanding the level of automation in the claims process. It helps identify manual intervention hotspots, measure the effectiveness of straight-through processing initiatives, and find new opportunities for automation by pinpointing repetitive, rule-based tasks currently performed by humans. Why it matters Distinguishes between system-driven and human-driven activities, which is key for automation analysis and identifying manual bottlenecks. Where to get This often needs to be derived. For example, events logged by a generic 'system' user can be flagged as automated. Examples truefalse | |||
| Is Rework IsRework | A flag indicating if an activity represents a rework loop, meaning a return to a previous process stage. | ||
| Description This calculated attribute flags activities that are part of a rework loop. For example, if the process moves from 'Investigation Completed' back to 'Investigation Started', the second 'Investigation Started' activity would be flagged as rework. Identifying rework is fundamental to uncovering process inefficiencies and quality issues. The Rework and Rejection Frequency dashboard relies on this metric to quantify how often claims deviate from the ideal 'happy path'. Analyzing the causes of rework can lead to significant improvements in process quality and speed. Why it matters Highlights process inefficiencies and quality issues by explicitly flagging activities that are part of a rework loop. Where to get This is calculated within the process mining tool by analyzing the sequence of activities for each case. Examples truefalse | |||
| Jurisdiction State JurisdictionState | The state or jurisdiction governing the claim, which dictates regulatory requirements. | ||
| Description This attribute specifies the legal jurisdiction (e.g., the US state) under which the claim is being handled. Insurance regulations can vary significantly between jurisdictions, impacting required process steps, communication timelines, and documentation. This is a vital attribute for compliance monitoring. Analyzing the process by jurisdiction ensures that state-specific regulatory requirements are being met. It can also explain variations in cycle times or process paths that are driven by legal constraints rather than operational inefficiency. Why it matters Crucial for compliance analysis, as different jurisdictions have different regulations that affect the claims process. Where to get A standard field on the Claim entity, typically named 'JurisdictionState'. Examples CANYTXFL | |||
| Last Data Update LastDataUpdate | The timestamp indicating when the data was last refreshed or extracted from the source system. | ||
| Description This attribute provides the timestamp of the most recent data pull from the source system. It is a metadata field that is essential for understanding the freshness of the analysis. Dashboards and analyses should display this information prominently so that users are aware of the data's currency. It helps in assessing whether the insights reflect the current state of operations or are based on older data. Why it matters Indicates the freshness of the data, ensuring users understand how current the process analysis is. Where to get This value is generated and stored during the ETL process, representing the timestamp of the data load. Examples 2024-07-28T04:00:00Z2024-07-29T04:00:00Z | |||
| Payment Amount PaymentAmount | The actual amount of money paid for a payment activity. | ||
| Description This attribute records the value of each individual payment made against a claim. A single claim can have multiple payments over its lifecycle. This is essential for financial analysis within the process mining context. It can be used to track the total payout per claim, analyze payment approval times based on amount, and link process inefficiencies to financial outcomes. For example, claims with long cycle times might correlate with higher total payments. Why it matters Tracks the financial transactions within a claim, enabling analysis of payment values and their relation to process activities. Where to get Found in Payment-related entities linked to the claim, often in a transaction or check table. Examples 4500.00125000.00500.00 | |||
| Policy Type PolicyType | The specific type of insurance policy under which the claim was filed. | ||
| Description Policy Type provides a more granular classification than Claim Type, detailing the specific insurance product, such as 'Homeowners', 'Commercial Auto', or 'Cyber Liability'. This level of detail can reveal process variations tied to specific products. Analyzing the process by Policy Type helps uncover product-specific inefficiencies. For example, claims for a newly launched policy might follow a less mature process, leading to delays. This analysis can inform product design and process standardization efforts. Why it matters Enables process analysis for specific insurance products, helping to identify variations in handling based on policy specifics. Where to get This information is located in the Policy entity, which is linked to the Claim. Examples Homeowners Multi-PerilCommercial Auto LiabilityInland Marine | |||
| Repeated Info Request RepeatedInfoRequestFlag | A flag that indicates if 'Additional Info Requested' has occurred more than once for the same claim. | ||
| Description This boolean flag is set to true if a claim has more than one 'Additional Info Requested' activity. This scenario often points to inefficiencies in the initial information-gathering phase. This attribute directly supports the 'Repeated Info Request Rate' KPI. It helps quantify the problem of incomplete initial fact-finding, which can lead to significant delays and customer frustration. Analyzing claims with this flag can help improve checklists and procedures for adjusters to ensure all necessary information is requested at once. Why it matters Identifies inefficiencies where information gathering is not done completely the first time, leading to process delays and rework. Where to get Calculated within the process mining tool by counting the occurrences of the 'Additional Info Requested' activity per case. Examples truefalse | |||
| Resolution Target Date ResolutionTargetDate | The date by which the claim is expected to be resolved according to internal or regulatory SLAs. | ||
| Description The Resolution Target Date is a deadline set for claim closure, often determined by factors like jurisdiction, claim type, and policy terms. It serves as a benchmark for measuring performance and compliance. This attribute is critical for building SLA adherence dashboards and KPIs. By comparing the actual 'Claim Closed' date to this target date, the analysis can automatically flag late claims, measure on-time performance rates, and identify which types of claims or departments are struggling to meet their targets. Why it matters This is the benchmark for measuring Service Level Agreement (SLA) adherence and identifying claims at risk of being late. Where to get This may be a custom field or derived based on business rules configured in ClaimCenter, possibly related to specific claim metrics. Examples 2023-06-142023-07-202023-08-28 | |||
| SLA Status SLAState | Indicates whether the claim was closed within its resolution target date. | ||
| Description This calculated attribute provides a categorical status of SLA adherence for each closed claim. It is derived by comparing the 'Claim Closed' activity's timestamp with the 'Resolution Target Date'. This attribute directly supports the 'Claim Resolution Target Adherence' dashboard by simplifying the analysis into clear categories like 'On Time' or 'Late'. It allows for easy filtering and aggregation to calculate the overall SLA adherence rate and to drill down into the reasons for delays. Why it matters Provides a clear, categorical outcome for SLA adherence, making it easy to filter, aggregate, and analyze on-time performance. Where to get Calculated field: IF (ActualCloseDate <= ResolutionTargetDate, 'On Time', 'Late'). Examples On TimeLate | |||
| Source System SourceSystem | The system from which the data was extracted. | ||
| Description This attribute identifies the origin of the event data. In a modern enterprise landscape, claim-related events might originate from multiple systems, such as a core system like Guidewire, a document management system, or a customer portal. Specifying the source system is crucial for data governance, troubleshooting data inconsistencies, and understanding the technological landscape of the process. It helps differentiate between core process steps and supporting activities from peripheral systems. Why it matters Identifies the data's origin, which is crucial for data governance and for analyses involving multiple integrated systems. Where to get This is typically a static value added during the data extraction, transformation, and loading (ETL) process. Examples Guidewire ClaimCenter v10Customer Portal APIDocumentum | |||
Claims Processing Activities
| Activity | Description | ||
|---|---|---|---|
| Claim Closed | Marks the successful closure of a claim after all activities and payments are complete. This is the primary successful end event, inferred from a change in the claim's main status. | ||
| Why it matters As the primary end event, this activity is essential for calculating end-to-end cycle time and measuring SLA adherence. It signifies the completion of the claim lifecycle. Where to get Inferred from a change in the State field of the cc_claim table to 'Closed'. The event timestamp is the CloseDate on the claim record. Capture Identify when the claim's master status field is updated to 'Closed'. Event type inferred | |||
| Claim Created | This activity marks the first notice of loss (FNOL) and the official creation of a new claim record in Guidewire ClaimCenter. It is captured explicitly when a new Claim entity is saved to the database for the first time. | ||
| Why it matters As the primary start event, this activity is essential for measuring the end-to-end claim cycle time. It provides the baseline for all subsequent performance and duration KPIs. Where to get This is an explicit event captured from the CreateTime of the cc_claim table. The creation of a new record with a unique Claim ID serves as the event trigger. Capture Identify the creation timestamp of the new record in the base Claim entity table. Event type explicit | |||
| Claim Denied | Represents the final decision to deny a claim, serving as a terminal endpoint for the process. This event is inferred from the claim's status changing to a closed state with a reason of 'Denied'. | ||
| Why it matters This is a critical outcome event. Analyzing the frequency, reasons, and process paths leading to denials helps identify issues with claim intake, investigation, or policy interpretation. Where to get Inferred from a change in the State field of the cc_claim table to 'Closed', combined with the CloseReason field being 'Denied' or a similar value. The event timestamp is the CloseDate. Capture Filter for claim status changes to 'Closed' where the reason code indicates denial. Event type inferred | |||
| Exposure Created | This activity signifies the creation of an exposure, which represents a specific potential liability or type of loss under the claim (e.g., vehicle damage, injury). This is an explicit event in Guidewire. | ||
| Why it matters Exposures are fundamental to claim segmentation and analysis. Tracking their creation helps understand process variations based on claim complexity and type of loss. Where to get Captured from the CreateTime of a new record in the cc_exposure table. Each record is linked back to a single Claim ID. Capture Identify the creation timestamp of a new record in the Exposure entity table. Event type explicit | |||
| Initial Reserve Set | Marks the creation of the first financial reserve transaction for an exposure, estimating the potential cost of the claim. This is a critical financial event and is captured explicitly. | ||
| Why it matters This milestone is key for financial analysis and understanding how quickly potential liability is assessed. Delays can impact financial planning and reporting. Where to get This event is captured from the creation of the first cc_reserveline record associated with an exposure on the claim. The transaction's CreateTime is the event timestamp. Capture Find the minimum creation timestamp of all reserve lines for a given claim's exposures. Event type explicit | |||
| Payment Approved | Represents the formal approval of a settlement payment. This is a critical audit event and is explicitly captured when a user with authority approves the transaction. | ||
| Why it matters This key milestone unblocks the final payment step. Analyzing time before and after this activity helps isolate delays caused by approval workflows or manager availability. Where to get This is often an explicit event logged in the cc_history table related to a cc_check or cc_transaction entity, recording a status change from 'Pending Approval' to 'Approved'. Capture Track the status change event to 'Approved' for a specific payment transaction. Event type explicit | |||
| Payment Issued | This activity marks the final step in the payment process, where the payment is officially issued and sent to the financial system. This is an explicit, logged financial transaction. | ||
| Why it matters This activity is crucial for measuring the efficiency of the payment dispatch process. It helps differentiate between approval delays and delays in the actual issuance of funds. Where to get Captured from the IssueDate or a status change to 'Issued' or 'Submitted' on the cc_check or cc_transaction entity. This is often an explicit timestamped event. Capture Identify the IssueDate or the timestamp of the status change to 'Issued' on the payment record. Event type explicit | |||
| Additional Info Received | Marks the completion of a request for additional information. This is captured when the corresponding 'Activity' (task) for information request is marked as 'Completed'. | ||
| Why it matters This is the endpoint for the 'Additional Info Gathering Cycle Time' KPI. Long durations between request and receipt are common sources of delay in the claims process. Where to get Captured from the CloseTime of a cc_activity record where the ActivityPattern relates to an information request. The status of the activity must be 'Completed'. Capture Identify the completion timestamp of a task for requesting external information. Event type explicit | |||
| Additional Info Requested | Represents a request sent to the claimant or a third party for more information or documentation. This is typically captured as an explicit 'Activity' (task) created in ClaimCenter. | ||
| Why it matters This activity is the starting point for measuring the 'Additional Info Gathering Cycle Time' KPI. Frequent occurrences can signal incomplete FNOL processes or inefficient information gathering. Where to get Captured from the CreateTime of a cc_activity record where the ActivityPattern is related to requesting documentation or information from an external party. Capture Identify the creation of a task for requesting external information. Event type explicit | |||
| Claim Assigned | Represents the assignment of a claim to a specific user (adjuster) or group for handling. This is typically inferred by monitoring changes to the assignment fields on the Claim entity. | ||
| Why it matters Tracking assignments is critical for analyzing adjuster workload, identifying routing bottlenecks, and measuring the time-to-first-action by the assigned handler. Where to get Inferred from the cc_history table by tracking changes to the AssignedUser or AssignedGroup fields associated with a specific Claim ID. The timestamp of the change indicates when the event occurred. Capture Monitor audit logs or history tables for updates to the claim assignment fields. Event type inferred | |||
| Claim Reopened | Represents a claim being moved from a 'Closed' state back to an 'Open' state to perform additional work. This event is inferred from a specific status change sequence. | ||
| Why it matters This activity signifies rework. High volumes of reopened claims indicate issues with initial settlement, missed damages, or other process failures, leading to increased costs and inefficiency. Where to get Inferred from the cc_history table by identifying a change in the State field of the cc_claim entity from 'Closed' back to 'Open' or another active state. Capture Monitor the claim's master status field for a transition from a closed state to an open one. Event type inferred | |||
| Investigation Started | Indicates the formal beginning of the investigation phase for a claim or exposure. This is often inferred from the creation of the first investigation-related 'Activity' (task) in Guidewire. | ||
| Why it matters This activity marks the start of a key, often lengthy, phase. Analyzing the time until investigation starts and the duration of the investigation itself reveals major bottlenecks. Where to get Inferred from the CreateTime of a cc_activity record where the ActivityPattern is related to investigation (e.g., 'Initial Investigation', 'Contact Witness'). Capture Identify the first creation of a task with an investigation-related pattern or subject. Event type inferred | |||
| Liability Decision Made | Signifies the point at which a decision on liability or fault has been determined for an exposure. This event is typically inferred from a status change on the Exposure entity. | ||
| Why it matters This is a critical decision milestone that gates the settlement and payment phases. Analyzing the time to this decision helps identify bottlenecks in the investigation and assessment stages. Where to get Inferred from the cc_history table by tracking a change in the State or a custom liability status field on the cc_exposure entity. The timestamp of the history record indicates the event time. Capture Monitor audit logs or history tables for updates to the exposure's state or liability status. Event type inferred | |||
| Settlement Calculated | This activity represents the point where a settlement amount has been determined but not yet approved for payment. It can be inferred from the creation of a payment in a 'Pending Approval' state. | ||
| Why it matters Marks the transition from assessment to payment. It's the starting point for measuring the 'Payment Authorization Lead Time' KPI, revealing delays in the approval chain. Where to get Inferred from the CreateTime of a cc_check or cc_transaction record where its initial status is 'Pending Approval' or a similar state before 'Approved'. Capture Identify the creation of a payment or transaction record in a pre-approved status. Event type inferred | |||
Extraction Guides
Steps
- Prerequisites Verification: Confirm you have the necessary permissions and credentials to access the Guidewire DataHub / InfoCenter data mart database with read privileges. Ensure the ETL jobs that populate the claims data mart are running successfully and the data is up-to-date.
- Database Connection: Use a standard SQL client (such as DBeaver, SQL Server Management Studio, or similar tools) to establish a connection to the data mart database server.
- Schema Exploration: Before running the full query, familiarize yourself with the data mart schema. Identify the primary tables for claims, exposures, activities, and financial transactions. Key tables are typically named with suffixes like _dim (dimension) and _fact (fact). This will help you validate the placeholder table and column names in the provided script.
- Prepare the SQL Query: Copy the complete SQL script provided in the query section into your SQL client's query editor.
- Customize Placeholders: Carefully review the script and replace all placeholder values. This includes the database/schema name (e.g., [YourDataMart]), date range parameters ('[StartDate]', '[EndDate]'), and any system-specific configuration values (e.g., activity patterns, status codes).
- Query Execution: Execute the modified SQL query against the data mart. The execution time may vary depending on the selected date range and the volume of data in your system.
- Initial Data Review: Once the query completes, inspect the first few hundred rows of the result set. Check that the columns ClaimID, ActivityName, and EventTime are populated as expected and that different activity types are present.
- Export to CSV: Export the entire result set from your SQL client to a CSV file. Name the file descriptively, for example, guidewire_claimcenter_event_log.csv.
- Format for ProcessMind: Ensure the CSV file is saved with UTF-8 encoding. Verify that the file has a header row matching the column aliases in the SQL query. The file is now ready to be uploaded to ProcessMind.
Configuration
- Data Source: Guidewire DataHub/InfoCenter Claims Data Mart. This is a pre-aggregated, dimensional database designed for reporting and analytics, separate from the live ClaimCenter production database.
- Required Authorizations: Read-only access to the SQL database hosting the data mart. You will need a username, password, and connection details (server address, database name).
- ETL Job Status: The accuracy of this extraction depends on the successful and timely execution of the Guidewire ETL jobs that populate the data mart. Verify the last successful run time to understand the data's freshness.
- Date Range Filtering: The provided query includes WHERE clauses with '[StartDate]' and '[EndDate]' placeholders. It is recommended to start with a limited date range (e.g., 3-6 months) to manage performance. The date filter is applied on the CreateTime of the claim.
- Configuration-Specific Values: Guidewire is highly configurable. You must adjust values in WHERE clauses to match your organization's setup. This includes:
- ActivityPattern names (e.g., 'fnol', 'investigation', 'Request additional information')
- ClaimStatus, ExposureStatus, and CloseReason codes (e.g., 'denied', 'closed')
- TransactionStatus codes (e.g., 'pendingapproval', 'approved', 'issued')
- Performance: Querying large history or audit tables can be resource-intensive. Executing the query during off-peak hours is recommended for very large datasets. Ensure the ClaimID or ClaimNumber columns are indexed on the relevant tables.
Sample Query sql
-- This query extracts a process mining event log for claims processing from a Guidewire DataHub/InfoCenter Data Mart.
-- Replace placeholders: [YourDataMart], [StartDate], [EndDate], and any configuration-specific string literals.
WITH ClaimHistory AS (
-- Pre-process claim history to identify status changes, especially for Reopened events.
SELECT
ClaimID,
Status,
UpdateTime,
LAG(Status, 1) OVER (PARTITION BY ClaimID ORDER BY UpdateTime) AS PreviousStatus
FROM [YourDataMart].[dbo].[ClaimHistory_dim] -- Placeholder for claim history/audit table
),
BaseClaims AS (
-- Select the set of claims to be analyzed based on a date range.
SELECT
c.ClaimID AS ClaimPublicID, -- Using PublicID as it's often the user-facing ID
c.ClaimNumber AS ClaimID,
c.AssignedAdjusterName AS AssignedAdjuster,
c.PolicyType AS ClaimType,
c.ClaimStatus AS ClaimStatus,
c.LossCause AS LossCause,
c.CreateTime
FROM [YourDataMart].[dbo].[Claim_dim] c
WHERE c.CreateTime >= '[StartDate]' AND c.CreateTime < '[EndDate]'
)
-- 1. Claim Created
SELECT
bc.ClaimID AS ClaimID,
'Claim Created' AS ActivityName,
bc.CreateTime AS EventTime,
bc.AssignedAdjuster,
bc.ClaimType,
bc.ClaimStatus,
bc.LossCause
FROM BaseClaims bc
UNION ALL
-- 2. Claim Assigned
-- This captures the first assignment event from the history table.
SELECT
bc.ClaimID,
'Claim Assigned' AS ActivityName,
MIN(ch.UpdateTime) AS EventTime,
bc.AssignedAdjuster,
bc.ClaimType,
bc.ClaimStatus,
bc.LossCause
FROM BaseClaims bc
JOIN [YourDataMart].[dbo].[ClaimHistory_dim] ch ON bc.ClaimPublicID = ch.ClaimID
WHERE ch.EventType = 'Assignment' -- Assumes an EventType column exists to identify assignment changes
GROUP BY bc.ClaimID, bc.AssignedAdjuster, bc.ClaimType, bc.ClaimStatus, bc.LossCause
UNION ALL
-- 3. Exposure Created
SELECT
bc.ClaimID,
'Exposure Created' AS ActivityName,
e.CreateTime AS EventTime,
bc.AssignedAdjuster,
bc.ClaimType,
bc.ClaimStatus,
bc.LossCause
FROM BaseClaims bc
JOIN [YourDataMart].[dbo].[Exposure_dim] e ON bc.ClaimPublicID = e.ClaimID
UNION ALL
-- 4. Initial Reserve Set
-- Finds the very first reserve transaction for any exposure on the claim.
SELECT
x.ClaimID,
'Initial Reserve Set' AS ActivityName,
x.EventTime,
x.AssignedAdjuster,
x.ClaimType,
x.ClaimStatus,
x.LossCause
FROM (
SELECT
bc.ClaimID,
t.CreateTime AS EventTime,
bc.AssignedAdjuster,
bc.ClaimType,
bc.ClaimStatus,
bc.LossCause,
ROW_NUMBER() OVER(PARTITION BY bc.ClaimID ORDER BY t.CreateTime) as rn
FROM BaseClaims bc
JOIN [YourDataMart].[dbo].[Transaction_fact] t ON bc.ClaimPublicID = t.ClaimID
WHERE t.TransactionType = 'Reserve'
) x
WHERE x.rn = 1
UNION ALL
-- 5. Investigation Started
-- Finds the creation of the first investigation-related activity.
SELECT
x.ClaimID,
'Investigation Started' AS ActivityName,
x.EventTime,
x.AssignedAdjuster,
x.ClaimType,
x.ClaimStatus,
x.LossCause
FROM (
SELECT
bc.ClaimID,
a.CreateTime AS EventTime,
bc.AssignedAdjuster,
bc.ClaimType,
bc.ClaimStatus,
bc.LossCause,
ROW_NUMBER() OVER(PARTITION BY bc.ClaimID ORDER BY a.CreateTime) as rn
FROM BaseClaims bc
JOIN [YourDataMart].[dbo].[Activity_dim] a ON bc.ClaimPublicID = a.ClaimID
WHERE a.ActivityPatternName LIKE '%Investigation%'
) x
WHERE x.rn = 1
UNION ALL
-- 6. Additional Info Requested
SELECT
bc.ClaimID,
'Additional Info Requested' AS ActivityName,
a.CreateTime AS EventTime,
bc.AssignedAdjuster,
bc.ClaimType,
bc.ClaimStatus,
bc.LossCause
FROM BaseClaims bc
JOIN [YourDataMart].[dbo].[Activity_dim] a ON bc.ClaimPublicID = a.ClaimID
WHERE a.ActivityPatternName LIKE '%Request%Information%'
UNION ALL
-- 7. Additional Info Received
SELECT
bc.ClaimID,
'Additional Info Received' AS ActivityName,
a.CompletionTime AS EventTime,
bc.AssignedAdjuster,
bc.ClaimType,
bc.ClaimStatus,
bc.LossCause
FROM BaseClaims bc
JOIN [YourDataMart].[dbo].[Activity_dim] a ON bc.ClaimPublicID = a.ClaimID
WHERE a.ActivityPatternName LIKE '%Request%Information%' AND a.CompletionTime IS NOT NULL
UNION ALL
-- 8. Liability Decision Made
-- Captures when an exposure's liability decision is first set.
SELECT
x.ClaimID,
'Liability Decision Made' AS ActivityName,
x.EventTime,
x.AssignedAdjuster,
x.ClaimType,
x.ClaimStatus,
x.LossCause
FROM (
SELECT
bc.ClaimID,
eh.UpdateTime AS EventTime,
bc.AssignedAdjuster,
bc.ClaimType,
bc.ClaimStatus,
bc.LossCause,
ROW_NUMBER() OVER(PARTITION BY bc.ClaimID ORDER BY eh.UpdateTime) as rn
FROM BaseClaims bc
JOIN [YourDataMart].[dbo].[ExposureHistory_dim] eh ON bc.ClaimPublicID = eh.ClaimID
WHERE eh.LiabilityDecision IS NOT NULL AND eh.PreviousLiabilityDecision IS NULL -- Captures the first time it was set
) x
WHERE x.rn = 1
UNION ALL
-- 9. Settlement Calculated
-- Captures the creation of a payment transaction that is pending approval.
SELECT
bc.ClaimID,
'Settlement Calculated' AS ActivityName,
t.CreateTime AS EventTime,
bc.AssignedAdjuster,
bc.ClaimType,
bc.ClaimStatus,
bc.LossCause
FROM BaseClaims bc
JOIN [YourDataMart].[dbo].[Transaction_fact] t ON bc.ClaimPublicID = t.ClaimID
WHERE t.TransactionType = 'Payment' AND t.TransactionStatus = 'PendingApproval'
UNION ALL
-- 10. Payment Approved
SELECT
bc.ClaimID,
'Payment Approved' AS ActivityName,
t.ApprovalDate AS EventTime,
bc.AssignedAdjuster,
bc.ClaimType,
bc.ClaimStatus,
bc.LossCause
FROM BaseClaims bc
JOIN [YourDataMart].[dbo].[Transaction_fact] t ON bc.ClaimPublicID = t.ClaimID
WHERE t.TransactionType = 'Payment' AND t.ApprovalDate IS NOT NULL AND t.TransactionStatus = 'Approved'
UNION ALL
-- 11. Payment Issued
SELECT
bc.ClaimID,
'Payment Issued' AS ActivityName,
t.IssueDate AS EventTime,
bc.AssignedAdjuster,
bc.ClaimType,
bc.ClaimStatus,
bc.LossCause
FROM BaseClaims bc
JOIN [YourDataMart].[dbo].[Transaction_fact] t ON bc.ClaimPublicID = t.ClaimID
WHERE t.TransactionType = 'Payment' AND t.IssueDate IS NOT NULL AND t.TransactionStatus = 'Issued'
UNION ALL
-- 12. Claim Denied
SELECT
bc.ClaimID,
'Claim Denied' AS ActivityName,
ch.UpdateTime AS EventTime,
bc.AssignedAdjuster,
bc.ClaimType,
'Denied' AS ClaimStatus, -- Overriding status for clarity
bc.LossCause
FROM BaseClaims bc
JOIN ClaimHistory ch ON bc.ClaimPublicID = ch.ClaimID
WHERE ch.Status = 'Closed' AND ch.PreviousStatus <> 'Closed'
AND EXISTS (SELECT 1 FROM [YourDataMart].[dbo].[Claim_dim] c2 WHERE c2.ClaimID = bc.ClaimPublicID AND c2.CloseReason = 'Denied')
UNION ALL
-- 13. Claim Closed
SELECT
bc.ClaimID,
'Claim Closed' AS ActivityName,
ch.UpdateTime AS EventTime,
bc.AssignedAdjuster,
bc.ClaimType,
'Closed' AS ClaimStatus, -- Overriding status for clarity
bc.LossCause
FROM BaseClaims bc
JOIN ClaimHistory ch ON bc.ClaimPublicID = ch.ClaimID
WHERE ch.Status = 'Closed' AND ch.PreviousStatus <> 'Closed'
AND NOT EXISTS (SELECT 1 FROM [YourDataMart].[dbo].[Claim_dim] c2 WHERE c2.ClaimID = bc.ClaimPublicID AND c2.CloseReason = 'Denied')
UNION ALL
-- 14. Claim Reopened
SELECT
bc.ClaimID,
'Claim Reopened' AS ActivityName,
ch.UpdateTime AS EventTime,
bc.AssignedAdjuster,
bc.ClaimType,
'Open' AS ClaimStatus, -- Overriding status for clarity
bc.LossCause
FROM BaseClaims bc
JOIN ClaimHistory ch ON bc.ClaimPublicID = ch.ClaimID
WHERE ch.PreviousStatus = 'Closed' AND ch.Status <> 'Closed'; Steps
- Confirm that your organization has an active Guidewire Cloud Data Access, CDA, Snowflake data share for the ClaimCenter environment, and obtain the Snowflake account identifier, database, schema, warehouse, role, authentication method, and authorized network configuration from your Guidewire Cloud administrator.
- Confirm the exact CDA database objects and columns exposed in your share. CDA schemas and column names can vary by tenant, release, configuration, and data-sharing model. Replace each bracketed object or column placeholder in the query with the corresponding object from your environment. Do not assume that operational ClaimCenter entity names are exposed unchanged in Snowflake.
- Identify the source for claim creation, claim assignment history, exposure creation, reserve transactions, activities, exposure status history, payment status history, and claim status history. If your share does not expose history tables or audit records, configure an approved source that preserves the prior value, new value, event timestamp, and actor for each required state transition.
- Connect to the CDA Snowflake share using an authorized Snowflake client, worksheet, notebook, or SQL execution tool. Use a read-only role where possible. Set the analysis start and end timestamps in the query using [Start timestamp] and [End timestamp], and apply any approved company or business-unit filter using [Company filter].
- Replace the source placeholders in the query with verified CDA object and column names. The query explicitly creates rows for all 14 required activities: Claim Created, Claim Assigned, Exposure Created, Initial Reserve Set, Investigation Started, Additional Info Requested, Additional Info Received, Liability Decision Made, Settlement Calculated, Payment Approved, Payment Issued, Claim Denied, Claim Closed, and Claim Reopened.
- Execute the query and review the result schema. The output must contain ClaimID, ActivityName, EventTime, AssignedAdjuster, ClaimType, ClaimStatus, and LossCause. ClaimID, ActivityName, and EventTime are required for ProcessMind. Preserve one row per event and do not aggregate events by claim.
- Validate timestamps, status transitions, assignment changes, duplicate handling, and activity counts before export. Confirm that event timestamps are in a consistent timezone and that multiple events with the same timestamp remain separate rows when they represent separate business activities.
- Export the result as UTF-8 CSV or another ProcessMind-supported tabular format. Map ClaimID as the case identifier, ActivityName as the activity, and EventTime as the event timestamp. Keep the recommended attributes as additional event attributes, and upload the file to ProcessMind without adding inferred activities outside this extraction.
Configuration
- Connection and authorization: Use the Guidewire-provided Snowflake data share through an authorized Snowflake account, role, warehouse, and network path. CDA is read-only from the consumer perspective. Required access depends on your tenant configuration and may include permission to query the shared database and the specific schemas or views.
- Source-object configuration: Replace all bracketed source references with objects verified in your CDA share. The query intentionally does not assert universal ClaimCenter table or column names because exposed CDA structures vary by release and tenant.
- Date range: Start with a three to six month period for validation and operational analysis. Use a wider range only after confirming warehouse capacity, event-history retention, and acceptable query duration. Filter source records by the relevant event timestamp, not only by claim creation date, so later activities are not excluded.
- Required output: ClaimID, ActivityName, and EventTime must be present and non-null for every event row. ActivityName must use the exact labels expected by the ProcessMind process model.
- Recommended output: Include AssignedAdjuster, ClaimType, ClaimStatus, and LossCause. These values may be taken from the event-time snapshot when available. If only current-state values are exposed, document that limitation because historical attributes may not reflect the value at the event time.
- Filters: Apply [Company filter] only after confirming the corresponding tenant-specific company, organization, business unit, or legal-entity column. Do not filter by document type unless the ClaimCenter configuration exposes a verified document-type field relevant to the requested activities.
- Event history: Assignment, investigation, information requests, liability decisions, payment states, and claim reopenings require history or audit data to identify transitions. Current-state tables alone cannot reliably reconstruct prior events.
- Deduplication: Use a verified source event identifier where available. The query uses ROW_NUMBER only as a configurable safeguard. Do not deduplicate events solely by ClaimID and timestamp when distinct activities can legitimately occur at the same time.
- Performance: Restrict the date range, select only required columns, filter each source by its event timestamp, and use an appropriately sized Snowflake warehouse. Consider materializing a validated event view or incremental extraction for large volumes.
- Timezone: Standardize EventTime to one documented timezone. Confirm whether CDA timestamps are stored as UTC, local time, or Snowflake timestamp variants before loading the event log.
- Prerequisites: Confirm that the required ClaimCenter financial, activity, assignment, exposure, payment, and status-history data is included in the share, and that retention policies preserve the required historical transitions.
Sample Query sql
WITH
params AS (
SELECT
TO_TIMESTAMP_TZ('[Start timestamp]') AS start_ts,
TO_TIMESTAMP_TZ('[End timestamp]') AS end_ts
),
claim_created AS (
SELECT
CAST(c.[Claim ID column] AS VARCHAR) AS ClaimID,
'Claim Created' AS ActivityName,
CAST(c.[Claim created timestamp column] AS TIMESTAMP_TZ) AS EventTime,
CAST(c.[Assigned adjuster column] AS VARCHAR) AS AssignedAdjuster,
CAST(c.[Claim type column] AS VARCHAR) AS ClaimType,
CAST(c.[Claim status column] AS VARCHAR) AS ClaimStatus,
CAST(c.[Loss cause column] AS VARCHAR) AS LossCause,
CAST(c.[Claim event identifier column] AS VARCHAR) AS SourceEventID
FROM [Your claim source object] c
CROSS JOIN params p
WHERE c.[Claim created timestamp column] >= p.start_ts
AND c.[Claim created timestamp column] < p.end_ts
AND [Company filter]
),
claim_assigned AS (
SELECT
CAST(h.[Claim ID column] AS VARCHAR) AS ClaimID,
'Claim Assigned' AS ActivityName,
CAST(h.[Assignment event timestamp column] AS TIMESTAMP_TZ) AS EventTime,
CAST(h.[New assigned adjuster column] AS VARCHAR) AS AssignedAdjuster,
CAST(h.[Claim type column] AS VARCHAR) AS ClaimType,
CAST(h.[Claim status column] AS VARCHAR) AS ClaimStatus,
CAST(h.[Loss cause column] AS VARCHAR) AS LossCause,
CAST(h.[Assignment event identifier column] AS VARCHAR) AS SourceEventID
FROM [Your claim assignment history object] h
CROSS JOIN params p
WHERE h.[Assignment event timestamp column] >= p.start_ts
AND h.[Assignment event timestamp column] < p.end_ts
AND h.[New assigned adjuster column] IS DISTINCT FROM h.[Previous assigned adjuster column]
AND [Company filter]
),
exposure_created AS (
SELECT
CAST(e.[Claim ID column] AS VARCHAR) AS ClaimID,
'Exposure Created' AS ActivityName,
CAST(e.[Exposure created timestamp column] AS TIMESTAMP_TZ) AS EventTime,
CAST(e.[Assigned adjuster column] AS VARCHAR) AS AssignedAdjuster,
CAST(e.[Claim type column] AS VARCHAR) AS ClaimType,
CAST(e.[Claim status column] AS VARCHAR) AS ClaimStatus,
CAST(e.[Loss cause column] AS VARCHAR) AS LossCause,
CAST(e.[Exposure event identifier column] AS VARCHAR) AS SourceEventID
FROM [Your exposure source object] e
CROSS JOIN params p
WHERE e.[Exposure created timestamp column] >= p.start_ts
AND e.[Exposure created timestamp column] < p.end_ts
AND [Company filter]
),
initial_reserve_set AS (
SELECT
CAST(r.[Claim ID column] AS VARCHAR) AS ClaimID,
'Initial Reserve Set' AS ActivityName,
CAST(r.[Reserve transaction timestamp column] AS TIMESTAMP_TZ) AS EventTime,
CAST(r.[Assigned adjuster column] AS VARCHAR) AS AssignedAdjuster,
CAST(r.[Claim type column] AS VARCHAR) AS ClaimType,
CAST(r.[Claim status column] AS VARCHAR) AS ClaimStatus,
CAST(r.[Loss cause column] AS VARCHAR) AS LossCause,
CAST(r.[Reserve transaction identifier column] AS VARCHAR) AS SourceEventID
FROM [Your reserve transaction source object] r
CROSS JOIN params p
WHERE r.[Reserve transaction timestamp column] >= p.start_ts
AND r.[Reserve transaction timestamp column] < p.end_ts
AND r.[Reserve transaction sequence or first reserve indicator column] = [Value identifying first reserve]
AND [Company filter]
),
investigation_started AS (
SELECT
CAST(a.[Claim ID column] AS VARCHAR) AS ClaimID,
'Investigation Started' AS ActivityName,
CAST(a.[Activity created timestamp column] AS TIMESTAMP_TZ) AS EventTime,
CAST(a.[Activity assigned user column] AS VARCHAR) AS AssignedAdjuster,
CAST(a.[Claim type column] AS VARCHAR) AS ClaimType,
CAST(a.[Claim status column] AS VARCHAR) AS ClaimStatus,
CAST(a.[Loss cause column] AS VARCHAR) AS LossCause,
CAST(a.[Activity identifier column] AS VARCHAR) AS SourceEventID
FROM [Your activity source object] a
CROSS JOIN params p
WHERE a.[Activity created timestamp column] >= p.start_ts
AND a.[Activity created timestamp column] < p.end_ts
AND a.[Activity category or type column] = '[Configured investigation activity value]'
AND [Company filter]
),
additional_info_requested AS (
SELECT
CAST(a.[Claim ID column] AS VARCHAR) AS ClaimID,
'Additional Info Requested' AS ActivityName,
CAST(a.[Activity created timestamp column] AS TIMESTAMP_TZ) AS EventTime,
CAST(a.[Activity assigned user column] AS VARCHAR) AS AssignedAdjuster,
CAST(a.[Claim type column] AS VARCHAR) AS ClaimType,
CAST(a.[Claim status column] AS VARCHAR) AS ClaimStatus,
CAST(a.[Loss cause column] AS VARCHAR) AS LossCause,
CAST(a.[Activity identifier column] AS VARCHAR) AS SourceEventID
FROM [Your activity source object] a
CROSS JOIN params p
WHERE a.[Activity created timestamp column] >= p.start_ts
AND a.[Activity created timestamp column] < p.end_ts
AND a.[Activity category or type column] = '[Configured additional information request value]'
AND [Company filter]
),
additional_info_received AS (
SELECT
CAST(a.[Claim ID column] AS VARCHAR) AS ClaimID,
'Additional Info Received' AS ActivityName,
CAST(a.[Activity completion timestamp column] AS TIMESTAMP_TZ) AS EventTime,
CAST(a.[Activity assigned user column] AS VARCHAR) AS AssignedAdjuster,
CAST(a.[Claim type column] AS VARCHAR) AS ClaimType,
CAST(a.[Claim status column] AS VARCHAR) AS ClaimStatus,
CAST(a.[Loss cause column] AS VARCHAR) AS LossCause,
CAST(a.[Activity identifier column] AS VARCHAR) AS SourceEventID
FROM [Your activity source object] a
CROSS JOIN params p
WHERE a.[Activity completion timestamp column] >= p.start_ts
AND a.[Activity completion timestamp column] < p.end_ts
AND a.[Activity category or type column] = '[Configured additional information request value]'
AND a.[Activity status column] = '[Configured completed status value]'
AND [Company filter]
),
liability_decision_made AS (
SELECT
CAST(eh.[Claim ID column] AS VARCHAR) AS ClaimID,
'Liability Decision Made' AS ActivityName,
CAST(eh.[Exposure status event timestamp column] AS TIMESTAMP_TZ) AS EventTime,
CAST(eh.[Assigned adjuster column] AS VARCHAR) AS AssignedAdjuster,
CAST(eh.[Claim type column] AS VARCHAR) AS ClaimType,
CAST(eh.[Claim status column] AS VARCHAR) AS ClaimStatus,
CAST(eh.[Loss cause column] AS VARCHAR) AS LossCause,
CAST(eh.[Exposure status event identifier column] AS VARCHAR) AS SourceEventID
FROM [Your exposure status history object] eh
CROSS JOIN params p
WHERE eh.[Exposure status event timestamp column] >= p.start_ts
AND eh.[Exposure status event timestamp column] < p.end_ts
AND eh.[New exposure status column] = '[Configured liability decision status value]'
AND eh.[New exposure status column] IS DISTINCT FROM eh.[Previous exposure status column]
AND [Company filter]
),
settlement_calculated AS (
SELECT
CAST(pay.[Claim ID column] AS VARCHAR) AS ClaimID,
'Settlement Calculated' AS ActivityName,
CAST(pay.[Payment created timestamp column] AS TIMESTAMP_TZ) AS EventTime,
CAST(pay.[Assigned adjuster column] AS VARCHAR) AS AssignedAdjuster,
CAST(pay.[Claim type column] AS VARCHAR) AS ClaimType,
CAST(pay.[Claim status column] AS VARCHAR) AS ClaimStatus,
CAST(pay.[Loss cause column] AS VARCHAR) AS LossCause,
CAST(pay.[Payment identifier column] AS VARCHAR) AS SourceEventID
FROM [Your payment source object] pay
CROSS JOIN params p
WHERE pay.[Payment created timestamp column] >= p.start_ts
AND pay.[Payment created timestamp column] < p.end_ts
AND pay.[Payment status column] = '[Configured pending approval status value]'
AND [Company filter]
),
payment_approved AS (
SELECT
CAST(ph.[Claim ID column] AS VARCHAR) AS ClaimID,
'Payment Approved' AS ActivityName,
CAST(ph.[Payment approval timestamp column] AS TIMESTAMP_TZ) AS EventTime,
CAST(ph.[Approving user column] AS VARCHAR) AS AssignedAdjuster,
CAST(ph.[Claim type column] AS VARCHAR) AS ClaimType,
CAST(ph.[Claim status column] AS VARCHAR) AS ClaimStatus,
CAST(ph.[Loss cause column] AS VARCHAR) AS LossCause,
CAST(ph.[Payment status event identifier column] AS VARCHAR) AS SourceEventID
FROM [Your payment status history object] ph
CROSS JOIN params p
WHERE ph.[Payment approval timestamp column] >= p.start_ts
AND ph.[Payment approval timestamp column] < p.end_ts
AND ph.[New payment status column] = '[Configured approved status value]'
AND ph.[New payment status column] IS DISTINCT FROM ph.[Previous payment status column]
AND [Company filter]
),
payment_issued AS (
SELECT
CAST(ph.[Claim ID column] AS VARCHAR) AS ClaimID,
'Payment Issued' AS ActivityName,
CAST(ph.[Payment issued timestamp column] AS TIMESTAMP_TZ) AS EventTime,
CAST(ph.[Issuing user column] AS VARCHAR) AS AssignedAdjuster,
CAST(ph.[Claim type column] AS VARCHAR) AS ClaimType,
CAST(ph.[Claim status column] AS VARCHAR) AS ClaimStatus,
CAST(ph.[Loss cause column] AS VARCHAR) AS LossCause,
CAST(ph.[Payment status event identifier column] AS VARCHAR) AS SourceEventID
FROM [Your payment status history object] ph
CROSS JOIN params p
WHERE ph.[Payment issued timestamp column] >= p.start_ts
AND ph.[Payment issued timestamp column] < p.end_ts
AND ph.[New payment status column] = '[Configured issued status value]'
AND ph.[New payment status column] IS DISTINCT FROM ph.[Previous payment status column]
AND [Company filter]
),
claim_denied AS (
SELECT
CAST(ch.[Claim ID column] AS VARCHAR) AS ClaimID,
'Claim Denied' AS ActivityName,
CAST(ch.[Claim status event timestamp column] AS TIMESTAMP_TZ) AS EventTime,
CAST(ch.[Assigned adjuster column] AS VARCHAR) AS AssignedAdjuster,
CAST(ch.[Claim type column] AS VARCHAR) AS ClaimType,
CAST(ch.[New claim status column] AS VARCHAR) AS ClaimStatus,
CAST(ch.[Loss cause column] AS VARCHAR) AS LossCause,
CAST(ch.[Claim status event identifier column] AS VARCHAR) AS SourceEventID
FROM [Your claim status history object] ch
CROSS JOIN params p
WHERE ch.[Claim status event timestamp column] >= p.start_ts
AND ch.[Claim status event timestamp column] < p.end_ts
AND ch.[New claim status column] = '[Configured closed status value]'
AND ch.[Claim closure reason column] = '[Configured denied reason value]'
AND ch.[New claim status column] IS DISTINCT FROM ch.[Previous claim status column]
AND [Company filter]
),
claim_closed AS (
SELECT
CAST(ch.[Claim ID column] AS VARCHAR) AS ClaimID,
'Claim Closed' AS ActivityName,
CAST(ch.[Claim status event timestamp column] AS TIMESTAMP_TZ) AS EventTime,
CAST(ch.[Assigned adjuster column] AS VARCHAR) AS AssignedAdjuster,
CAST(ch.[Claim type column] AS VARCHAR) AS ClaimType,
CAST(ch.[New claim status column] AS VARCHAR) AS ClaimStatus,
CAST(ch.[Loss cause column] AS VARCHAR) AS LossCause,
CAST(ch.[Claim status event identifier column] AS VARCHAR) AS SourceEventID
FROM [Your claim status history object] ch
CROSS JOIN params p
WHERE ch.[Claim status event timestamp column] >= p.start_ts
AND ch.[Claim status event timestamp column] < p.end_ts
AND ch.[New claim status column] = '[Configured closed status value]'
AND COALESCE(ch.[Claim closure reason column], '') <> '[Configured denied reason value]'
AND ch.[New claim status column] IS DISTINCT FROM ch.[Previous claim status column]
AND [Company filter]
),
claim_reopened AS (
SELECT
CAST(ch.[Claim ID column] AS VARCHAR) AS ClaimID,
'Claim Reopened' AS ActivityName,
CAST(ch.[Claim status event timestamp column] AS TIMESTAMP_TZ) AS EventTime,
CAST(ch.[Assigned adjuster column] AS VARCHAR) AS AssignedAdjuster,
CAST(ch.[Claim type column] AS VARCHAR) AS ClaimType,
CAST(ch.[New claim status column] AS VARCHAR) AS ClaimStatus,
CAST(ch.[Loss cause column] AS VARCHAR) AS LossCause,
CAST(ch.[Claim status event identifier column] AS VARCHAR) AS SourceEventID
FROM [Your claim status history object] ch
CROSS JOIN params p
WHERE ch.[Claim status event timestamp column] >= p.start_ts
AND ch.[Claim status event timestamp column] < p.end_ts
AND ch.[Previous claim status column] = '[Configured closed status value]'
AND ch.[New claim status column] = '[Configured open status value]'
AND ch.[New claim status column] IS DISTINCT FROM ch.[Previous claim status column]
AND [Company filter]
),
all_events AS (
SELECT * FROM claim_created
UNION ALL SELECT * FROM claim_assigned
UNION ALL SELECT * FROM exposure_created
UNION ALL SELECT * FROM initial_reserve_set
UNION ALL SELECT * FROM investigation_started
UNION ALL SELECT * FROM additional_info_requested
UNION ALL SELECT * FROM additional_info_received
UNION ALL SELECT * FROM liability_decision_made
UNION ALL SELECT * FROM settlement_calculated
UNION ALL SELECT * FROM payment_approved
UNION ALL SELECT * FROM payment_issued
UNION ALL SELECT * FROM claim_denied
UNION ALL SELECT * FROM claim_closed
UNION ALL SELECT * FROM claim_reopened
),
deduplicated_events AS (
SELECT
ClaimID,
ActivityName,
EventTime,
AssignedAdjuster,
ClaimType,
ClaimStatus,
LossCause,
SourceEventID,
ROW_NUMBER() OVER (
PARTITION BY ActivityName, COALESCE(SourceEventID, ClaimID || '|' || TO_VARCHAR(EventTime))
ORDER BY EventTime
) AS duplicate_rank
FROM all_events
WHERE ClaimID IS NOT NULL
AND ActivityName IS NOT NULL
AND EventTime IS NOT NULL
)
SELECT
ClaimID,
ActivityName,
EventTime,
AssignedAdjuster,
ClaimType,
ClaimStatus,
LossCause
FROM deduplicated_events
WHERE duplicate_rank = 1
ORDER BY ClaimID, EventTime, ActivityName; Steps
- Confirm that direct read access to the on-premise Guidewire ClaimCenter operational database is authorized, that the database platform and schema version are documented, and that a read-only connection is available. Do not query the production database without an approved extraction window.
- Identify the physical tables and columns used by your ClaimCenter implementation. Map the claim, exposure, activity, assignment, reserve, payment, status history, and user or group entities to the placeholders in the query. Because physical names and audit structures vary by implementation and version, replace each placeholder only after validating it against your database catalog and ClaimCenter data model.
- Define the extraction period using [Start date parameter] and [End date parameter]. Use a rolling overlap, such as one or two days before the requested start date, when status changes, task completion, or financial transactions can be recorded outside the primary claim creation period.
- Execute the complete SQL statement with read-only privileges. Each activity is emitted as an explicit event row. The query does not rely on ProcessMind to infer events after ingestion. Events inferred from field changes are derived inside the SQL statement from the relevant history or audit records.
- Validate the source mappings for each activity. Confirm that claim creation uses the first saved Claim record, assignment uses assignment changes, exposure creation uses exposure creation records, initial reserve uses the first reserve transaction per exposure, investigation and information requests use activity records, liability uses the configured exposure status transition, settlement uses a pending approval payment state, and payment approval and issuance use their corresponding financial audit states.
- Normalize the output to the required event-log structure. ClaimID must be the case identifier, ActivityName must contain exactly one of the fourteen documented activity names, and EventTime must be a timestamp. Preserve the recommended attributes, including AssignedAdjuster, ClaimType, ClaimStatus, and LossCause, when the source mapping provides them.
- Review duplicate events and event ordering. If the source contains multiple audit rows for the same business transition, apply the implementation-specific deduplication key in the relevant common table expression. Do not collapse distinct business events that have different timestamps or source identifiers.
- Export the result as UTF-8 CSV or another ProcessMind-supported tabular format. Include a header row with ClaimID, ActivityName, EventTime, AssignedAdjuster, ClaimType, ClaimStatus, and LossCause. Ensure timestamps include timezone information or use the documented database timezone consistently. Upload the file to ProcessMind and map ClaimID as the case identifier, ActivityName as the activity, and EventTime as the event timestamp.
Configuration
- Database access: Use a read-only account with permission to query the required ClaimCenter operational tables, history tables, activity tables, and financial transaction tables. Do not grant write, schema modification, or administrative privileges for extraction.
- Schema mapping: Replace [Your claim table], [Your exposure table], [Your activity table], [Your reserve table], [Your payment table], [Your claim history table], [Your exposure history table], and related placeholders with names verified in the target implementation. Do not assume that a logical Guidewire entity name is the physical database table name.
- Date range: Start with three to six months of data. Use [Start date parameter] and [End date parameter] and include an overlap window when events can be recorded after claim creation or when reopened claims span multiple reporting periods.
- Filters: Apply [Company Code filter], [Document Type filter], jurisdiction, line of business, or other organization-specific filters only after confirming their physical columns and business meaning. Avoid filtering out claims that have no payment or no exposure because those records are needed for complete lifecycle analysis.
- Activity names: Keep the fourteen ActivityName values exactly as defined in the query so ProcessMind receives consistent event labels.
- Event semantics: Activities described as inferred are generated from source status, assignment, history, or activity transitions in SQL. ProcessMind will not derive these events from other rows after ingestion.
- Performance: Restrict the extraction period, select only required columns, filter source tables before joins, and verify indexes on claim identifiers, exposure identifiers, event timestamps, status fields, and transaction identifiers. Run large extractions against a reporting replica where available.
- Consistency: Use a transaction isolation level appropriate for reporting and capture a consistent extraction boundary. Avoid reading tables while a financial batch or bulk status update is partially committed.
- Time zones: Document the database timezone and convert all source timestamps to one agreed timezone before export. Do not mix application-local and database-server timestamps.
- Prerequisites: Confirm the required ClaimCenter modules, financial permissions, audit or history retention, and database connectivity are available. If history or audit retention is disabled, the corresponding inferred activities cannot be reconstructed reliably.
- Validation configuration: Record the ClaimCenter version, database platform, schema mapping, extraction timestamp, date parameters, filters, and row counts with each export.
Sample Query sql
WITH
claim_created AS (
SELECT
c.[Claim ID column] AS ClaimID,
CAST('Claim Created' AS VARCHAR(100)) AS ActivityName,
c.[Claim Created Timestamp column] AS EventTime,
c.[Assigned Adjuster column] AS AssignedAdjuster,
c.[Claim Type column] AS ClaimType,
c.[Claim Status column] AS ClaimStatus,
c.[Loss Cause column] AS LossCause
FROM [Your claim table] c
WHERE c.[Claim Created Timestamp column] >= [Start date parameter]
AND c.[Claim Created Timestamp column] < [End date parameter]
),
claim_assigned AS (
SELECT
h.[Claim ID column] AS ClaimID,
CAST('Claim Assigned' AS VARCHAR(100)) AS ActivityName,
h.[Assignment Change Timestamp column] AS EventTime,
h.[Assigned Adjuster column] AS AssignedAdjuster,
c.[Claim Type column] AS ClaimType,
h.[Claim Status column] AS ClaimStatus,
c.[Loss Cause column] AS LossCause
FROM [Your claim assignment history table] h
INNER JOIN [Your claim table] c
ON c.[Claim ID column] = h.[Claim ID column]
WHERE h.[Assignment Change Timestamp column] >= [Start date parameter]
AND h.[Assignment Change Timestamp column] < [End date parameter]
AND h.[Assigned Adjuster column] IS NOT NULL
),
exposure_created AS (
SELECT
e.[Claim ID column] AS ClaimID,
CAST('Exposure Created' AS VARCHAR(100)) AS ActivityName,
e.[Exposure Created Timestamp column] AS EventTime,
c.[Assigned Adjuster column] AS AssignedAdjuster,
c.[Claim Type column] AS ClaimType,
c.[Claim Status column] AS ClaimStatus,
c.[Loss Cause column] AS LossCause
FROM [Your exposure table] e
INNER JOIN [Your claim table] c
ON c.[Claim ID column] = e.[Claim ID column]
WHERE e.[Exposure Created Timestamp column] >= [Start date parameter]
AND e.[Exposure Created Timestamp column] < [End date parameter]
),
initial_reserve_set AS (
SELECT
x.ClaimID,
CAST('Initial Reserve Set' AS VARCHAR(100)) AS ActivityName,
x.EventTime,
x.AssignedAdjuster,
x.ClaimType,
x.ClaimStatus,
x.LossCause
FROM (
SELECT
r.[Claim ID column] AS ClaimID,
r.[Reserve Timestamp column] AS EventTime,
c.[Assigned Adjuster column] AS AssignedAdjuster,
c.[Claim Type column] AS ClaimType,
c.[Claim Status column] AS ClaimStatus,
c.[Loss Cause column] AS LossCause,
ROW_NUMBER() OVER (
PARTITION BY r.[Exposure ID column]
ORDER BY r.[Reserve Timestamp column], r.[Reserve Transaction ID column]
) AS reserve_sequence
FROM [Your reserve transaction table] r
INNER JOIN [Your claim table] c
ON c.[Claim ID column] = r.[Claim ID column]
WHERE r.[Reserve Timestamp column] >= [Start date parameter]
AND r.[Reserve Timestamp column] < [End date parameter]
) x
WHERE x.reserve_sequence = 1
),
investigation_started AS (
SELECT
a.[Claim ID column] AS ClaimID,
CAST('Investigation Started' AS VARCHAR(100)) AS ActivityName,
a.[Activity Created Timestamp column] AS EventTime,
a.[Assigned User column] AS AssignedAdjuster,
c.[Claim Type column] AS ClaimType,
c.[Claim Status column] AS ClaimStatus,
c.[Loss Cause column] AS LossCause
FROM [Your activity table] a
INNER JOIN [Your claim table] c
ON c.[Claim ID column] = a.[Claim ID column]
WHERE a.[Activity Created Timestamp column] >= [Start date parameter]
AND a.[Activity Created Timestamp column] < [End date parameter]
AND a.[Activity Type column] IN ([Investigation activity type value])
),
additional_info_requested AS (
SELECT
a.[Claim ID column] AS ClaimID,
CAST('Additional Info Requested' AS VARCHAR(100)) AS ActivityName,
a.[Activity Created Timestamp column] AS EventTime,
a.[Assigned User column] AS AssignedAdjuster,
c.[Claim Type column] AS ClaimType,
c.[Claim Status column] AS ClaimStatus,
c.[Loss Cause column] AS LossCause
FROM [Your activity table] a
INNER JOIN [Your claim table] c
ON c.[Claim ID column] = a.[Claim ID column]
WHERE a.[Activity Created Timestamp column] >= [Start date parameter]
AND a.[Activity Created Timestamp column] < [End date parameter]
AND a.[Activity Type column] IN ([Additional information request activity type value])
),
additional_info_received AS (
SELECT
a.[Claim ID column] AS ClaimID,
CAST('Additional Info Received' AS VARCHAR(100)) AS ActivityName,
a.[Activity Completed Timestamp column] AS EventTime,
a.[Assigned User column] AS AssignedAdjuster,
c.[Claim Type column] AS ClaimType,
c.[Claim Status column] AS ClaimStatus,
c.[Loss Cause column] AS LossCause
FROM [Your activity table] a
INNER JOIN [Your claim table] c
ON c.[Claim ID column] = a.[Claim ID column]
WHERE a.[Activity Completed Timestamp column] >= [Start date parameter]
AND a.[Activity Completed Timestamp column] < [End date parameter]
AND a.[Activity Type column] IN ([Additional information request activity type value])
AND a.[Activity Status column] = [Completed activity status value]
),
liability_decision_made AS (
SELECT
h.[Claim ID column] AS ClaimID,
CAST('Liability Decision Made' AS VARCHAR(100)) AS ActivityName,
h.[Status Change Timestamp column] AS EventTime,
c.[Assigned Adjuster column] AS AssignedAdjuster,
c.[Claim Type column] AS ClaimType,
c.[Claim Status column] AS ClaimStatus,
c.[Loss Cause column] AS LossCause
FROM [Your exposure status history table] h
INNER JOIN [Your claim table] c
ON c.[Claim ID column] = h.[Claim ID column]
WHERE h.[Status Change Timestamp column] >= [Start date parameter]
AND h.[Status Change Timestamp column] < [End date parameter]
AND h.[New Exposure Status column] IN ([Liability decision status value])
),
settlement_calculated AS (
SELECT
p.[Claim ID column] AS ClaimID,
CAST('Settlement Calculated' AS VARCHAR(100)) AS ActivityName,
p.[Payment Status Timestamp column] AS EventTime,
c.[Assigned Adjuster column] AS AssignedAdjuster,
c.[Claim Type column] AS ClaimType,
c.[Claim Status column] AS ClaimStatus,
c.[Loss Cause column] AS LossCause
FROM [Your payment table] p
INNER JOIN [Your claim table] c
ON c.[Claim ID column] = p.[Claim ID column]
WHERE p.[Payment Status Timestamp column] >= [Start date parameter]
AND p.[Payment Status Timestamp column] < [End date parameter]
AND p.[Payment Status column] = [Pending approval payment status value]
),
payment_approved AS (
SELECT
p.[Claim ID column] AS ClaimID,
CAST('Payment Approved' AS VARCHAR(100)) AS ActivityName,
p.[Approval Timestamp column] AS EventTime,
p.[Approved By column] AS AssignedAdjuster,
c.[Claim Type column] AS ClaimType,
c.[Claim Status column] AS ClaimStatus,
c.[Loss Cause column] AS LossCause
FROM [Your payment approval history table] p
INNER JOIN [Your claim table] c
ON c.[Claim ID column] = p.[Claim ID column]
WHERE p.[Approval Timestamp column] >= [Start date parameter]
AND p.[Approval Timestamp column] < [End date parameter]
AND p.[Approval Status column] = [Approved payment status value]
),
payment_issued AS (
SELECT
p.[Claim ID column] AS ClaimID,
CAST('Payment Issued' AS VARCHAR(100)) AS ActivityName,
p.[Issued Timestamp column] AS EventTime,
p.[Approved By column] AS AssignedAdjuster,
c.[Claim Type column] AS ClaimType,
c.[Claim Status column] AS ClaimStatus,
c.[Loss Cause column] AS LossCause
FROM [Your payment issuance table] p
INNER JOIN [Your claim table] c
ON c.[Claim ID column] = p.[Claim ID column]
WHERE p.[Issued Timestamp column] >= [Start date parameter]
AND p.[Issued Timestamp column] < [End date parameter]
AND p.[Payment Status column] = [Issued payment status value]
),
claim_denied AS (
SELECT
h.[Claim ID column] AS ClaimID,
CAST('Claim Denied' AS VARCHAR(100)) AS ActivityName,
h.[Status Change Timestamp column] AS EventTime,
c.[Assigned Adjuster column] AS AssignedAdjuster,
c.[Claim Type column] AS ClaimType,
h.[New Claim Status column] AS ClaimStatus,
c.[Loss Cause column] AS LossCause
FROM [Your claim status history table] h
INNER JOIN [Your claim table] c
ON c.[Claim ID column] = h.[Claim ID column]
WHERE h.[Status Change Timestamp column] >= [Start date parameter]
AND h.[Status Change Timestamp column] < [End date parameter]
AND h.[New Claim Status column] = [Closed claim status value]
AND h.[Status Reason column] = [Denied status reason value]
),
claim_closed AS (
SELECT
h.[Claim ID column] AS ClaimID,
CAST('Claim Closed' AS VARCHAR(100)) AS ActivityName,
h.[Status Change Timestamp column] AS EventTime,
c.[Assigned Adjuster column] AS AssignedAdjuster,
c.[Claim Type column] AS ClaimType,
h.[New Claim Status column] AS ClaimStatus,
c.[Loss Cause column] AS LossCause
FROM [Your claim status history table] h
INNER JOIN [Your claim table] c
ON c.[Claim ID column] = h.[Claim ID column]
WHERE h.[Status Change Timestamp column] >= [Start date parameter]
AND h.[Status Change Timestamp column] < [End date parameter]
AND h.[New Claim Status column] = [Closed claim status value]
AND h.[Status Reason column] <> [Denied status reason value]
),
claim_reopened AS (
SELECT
h.[Claim ID column] AS ClaimID,
CAST('Claim Reopened' AS VARCHAR(100)) AS ActivityName,
h.[Status Change Timestamp column] AS EventTime,
c.[Assigned Adjuster column] AS AssignedAdjuster,
c.[Claim Type column] AS ClaimType,
h.[New Claim Status column] AS ClaimStatus,
c.[Loss Cause column] AS LossCause
FROM [Your claim status history table] h
INNER JOIN [Your claim status history table] previous_h
ON previous_h.[Claim ID column] = h.[Claim ID column]
AND previous_h.[Status Change Timestamp column] = (
SELECT MAX(prior_h.[Status Change Timestamp column])
FROM [Your claim status history table] prior_h
WHERE prior_h.[Claim ID column] = h.[Claim ID column]
AND prior_h.[Status Change Timestamp column] < h.[Status Change Timestamp column]
)
INNER JOIN [Your claim table] c
ON c.[Claim ID column] = h.[Claim ID column]
WHERE h.[Status Change Timestamp column] >= [Start date parameter]
AND h.[Status Change Timestamp column] < [End date parameter]
AND previous_h.[New Claim Status column] = [Closed claim status value]
AND h.[New Claim Status column] = [Open claim status value]
)
SELECT ClaimID, ActivityName, EventTime, AssignedAdjuster, ClaimType, ClaimStatus, LossCause FROM claim_created
UNION ALL
SELECT ClaimID, ActivityName, EventTime, AssignedAdjuster, ClaimType, ClaimStatus, LossCause FROM claim_assigned
UNION ALL
SELECT ClaimID, ActivityName, EventTime, AssignedAdjuster, ClaimType, ClaimStatus, LossCause FROM exposure_created
UNION ALL
SELECT ClaimID, ActivityName, EventTime, AssignedAdjuster, ClaimType, ClaimStatus, LossCause FROM initial_reserve_set
UNION ALL
SELECT ClaimID, ActivityName, EventTime, AssignedAdjuster, ClaimType, ClaimStatus, LossCause FROM investigation_started
UNION ALL
SELECT ClaimID, ActivityName, EventTime, AssignedAdjuster, ClaimType, ClaimStatus, LossCause FROM additional_info_requested
UNION ALL
SELECT ClaimID, ActivityName, EventTime, AssignedAdjuster, ClaimType, ClaimStatus, LossCause FROM additional_info_received
UNION ALL
SELECT ClaimID, ActivityName, EventTime, AssignedAdjuster, ClaimType, ClaimStatus, LossCause FROM liability_decision_made
UNION ALL
SELECT ClaimID, ActivityName, EventTime, AssignedAdjuster, ClaimType, ClaimStatus, LossCause FROM settlement_calculated
UNION ALL
SELECT ClaimID, ActivityName, EventTime, AssignedAdjuster, ClaimType, ClaimStatus, LossCause FROM payment_approved
UNION ALL
SELECT ClaimID, ActivityName, EventTime, AssignedAdjuster, ClaimType, ClaimStatus, LossCause FROM payment_issued
UNION ALL
SELECT ClaimID, ActivityName, EventTime, AssignedAdjuster, ClaimType, ClaimStatus, LossCause FROM claim_denied
UNION ALL
SELECT ClaimID, ActivityName, EventTime, AssignedAdjuster, ClaimType, ClaimStatus, LossCause FROM claim_closed
UNION ALL
SELECT ClaimID, ActivityName, EventTime, AssignedAdjuster, ClaimType, ClaimStatus, LossCause FROM claim_reopened
ORDER BY ClaimID, EventTime, ActivityName; Ready to Get Started?
Leverage this template to prepare your data for analysis and unlock insights into your claims processing. Start optimizing your workflows today.
Accelerate Claims Processing, Resolve Cases Faster Now
Eliminate backlogs, prevent fraud, and target 70% straight-through processing.
No credit card required, setup in just minutes.