FSO Disputes Data Model and Core Data Objects
Objective
The FSO Disputes data model is built on a clear table inheritance chain: Now Platform (task), then CSM Case (sn_customerservice_case), then Card Disputes Service Case (sn_bom_credit_card_disputes_service). Dispute cases inherit all CSM behaviors, including workspace views, task routing, SLAs, and customer/account relationships, while FSO adds disputes-specific fields, playbook stages, and compliance logic on top. This article covers the core tables, their relationships, the questionnaire data model, and the key fields that drive workflow routing, SLA calculation, and regulatory compliance.
For the full data model reference, see FSO Disputes Data Model in the ServiceNow Docs.
Core Tables
The following tables are central to FSO Disputes. For a complete list of tables installed with the base application and each content pack, refer to the SN Docs link above.
| Table Name | Purpose | Key Fields / Notes |
|---|---|---|
| Card Disputes Service Case [sn_bom_credit_card_disputes_service] | Core dispute case. Extends CSM Case (sn_customerservice_case). | Dispute type, status, channel, claim amount, resolution code, regulatory deadline. Top-level record for the entire dispute lifecycle. |
| Card Disputes Task [sn_bom_credit_card_disputes_task] | Individual workflow tasks within a dispute case. | Task type (e.g. Issue Provisional Credit, Report Fraud, Investigate), SLA, stage assignment (Investigate / Chargeback / Closure). Reg E SLAs attach here. |
| Card Disputes Transaction [sn_bom_credit_card_disputes_transaction] | One record per disputed transaction within a case. | Transaction ID, amount, merchant, network, chargeback eligibility, policy (IPC/IFC/No Credit), dispute reported date, card/account reference. |
| Intake Form [sn_evnt_inq_qtn] | Base table for all dispute intake questionnaire data (Event Inquiry application). | Questionnaire questions and answers per dispute category and network. Extended by Visa and Mastercard network-specific intake tables. |
| Intake Form Label [sn_evnt_inq_question] | Provides surface-specific labels for intake fields. | Admins map different label text for agent workspace vs. customer portal intake, sharing the same underlying column. |
| Visa Dispute Intake [sn_bom_visa_cp_visa_dispute_questionnaire] | Stores Visa-specific questionnaire responses. Extends Intake Form. | Installed with Dispute Rules Content Pack for Visa. Covers all Visa dispute categories: Fraud, Authorization, Processing Errors, Consumer Disputes. |
| Visa Dispute Cardholder Intake [sn_bom_visa_cp_visa_dispute_cardholder_intake] | Portal-facing Visa questionnaire responses. Extends Visa Dispute Intake. | Responses submitted by consumers (not agents) via the Customer or Consumer Service Portal. |
| CRB Region Type [sn_bom_visa_cp_crb_region_type] | Stores Visa Card Recovery Bulletin (CRB) regions. | Used in Visa chargeback eligibility evaluation. Installed with Dispute Rules Content Pack for Visa. |
| Mastercard Chargeback Reason Code Message [sn_bom_mcard_cp_mastercard_chargeback_reason_codes] | Mastercard chargeback reason codes and associated messages. | Installed with Dispute Rules Content Pack for Mastercard. Used to auto-determine reason code from questionnaire responses. |
| Tokenizer Resource Configuration [sn_data_sec_resource_config] | Maps REST message functions to tokenizer service endpoints for Card Data Security. | HTTP method, API path, target system (VROL / Mastercom), REST message function. Installed with Card Data Security. |
Questionnaire Data Model and Intake Inheritance
The dispute intake questionnaire uses the Event Inquiry application, which manages all intake questions and automates their collection. The Event Inquiry application owns the base Intake Form [sn_evnt_inq_qtn] table. The Financial Services Card Operations application extends this with dispute-specific intake tables: Dispute Intake (agent-facing questions) and Cardholder Dispute Intake (cardholder-facing questions for portal intake). Network-specific intake tables for Visa extend this hierarchy further via the Dispute Rules Content Pack for Visa.
This separation of agent and cardholder intake tables allows the same underlying data field to display different label text to agents in the workspace versus cardholders on the portal, configured via the Intake Form Label table without changing the underlying schema.
Table Relationships and Implementation Considerations
- A single Card Disputes Service Case can contain multiple Card Disputes Transaction records. For Fraud category disputes, agents can add multiple transactions to one case.
- Tasks are generated by policy rule evaluation at case submission, for example, a Fraud category case automatically creates a Block and Reissue Card task running in parallel with the main dispute flow.
- Reg E SLAs attach to both the Card Disputes Task (provisional credit timers) and the Card Disputes Service Case (resolution timers). Knowing which SLA lives on which table is critical for accurate reporting and breach monitoring.
- Visa and Mastercard have dedicated intake tables installed by their respective content packs. ACH disputes use the base intake table with Nacha reason code logic applied via decision tables.
- The same underlying field can show different label text to agents (workspace) versus cardholders (portal) by configuring separate label records in the Intake Form Label table, with no schema change needed.
Field Definitions in FSO Disputes
The following table covers key fields on the Card Disputes Service Case and Card Disputes Transaction tables that directly affect workflow routing, SLA calculation, and regulatory compliance. For the complete field reference, see FSO Disputes Data Model in the ServiceNow Docs.
| Field | Data Type | Description | Implementation Note |
|---|---|---|---|
| Dispute Type | Choice (card / non-card / ACH) | Classifies the dispute. Card types route to Visa or Mastercard workflows; ACH routes to Nacha workflow. | Drives playbook, SLA, and content pack routing. |
| Dispute Channel | Choice | Intake channel: Workspace (agent), Portal (customer), Virtual Agent, Branch, Phone. | Determines if Review stage is triggered. Portal/contributor intake routes to Review; agent-direct skips it. |
| Dispute Category | Choice (Fraud / Authorization / Processing Errors / Consumer Disputes) | Determined by tiered questionnaire (Levels 1 and 2 mandatory; Level 3 optional) during intake. | Fraud category enables multi-transaction selection and triggers Block/Reissue Card task in parallel. |
| Reason Code | Choice (network-specific) | Derived from dispute category and questionnaire answers per Visa, Mastercard, or Nacha guidelines. | Auto-determined when a content pack is installed. Manual mapping required for other networks. |
| Dispute Reported Date | DateTime | Automatically set to current date/time when a transaction is selected during intake. | All regulatory SLA clocks calculate from this field. Cannot be set to a future date after population. |
| Policy (per transaction) | Choice (Immediate Provisional Credit / Immediate Final Credit / No Credit) | Policy rule outcome per transaction evaluated at case submission. | Drives Issue Provisional Credit and Determine Recovery Option activities in the Investigate stage. |
| Is New Financial Account? | Boolean | Presented at submission. Affects SLA tier under Reg E (extended windows for new accounts). | Only relevant when Dispute Content Pack for US Regulations is installed. |
| Acknowledgement Sent | Boolean | Agent-set flag confirming dispute acknowledgement has been issued to the cardholder. | Marks Reg E and Reg Z acknowledgement SLAs as complete when set to Yes. |
| Resolution Code | Choice | Agent-entered at Closure stage. Indicates final outcome of the dispute. | Required before case can be closed to Closed Complete state. |
| Chargeback Eligibility | System-evaluated | Evaluated at submission based on reason code and questionnaire responses. | If ineligible and agent selects Pursue Chargeback, triggers a dispute manager approval task (4-eyes policy). |
What's Next
Continue exploring FSO Disputes with these related resources:
- For the complete FSO Disputes table and field reference, see FSO Disputes Data Model in the ServiceNow Docs.
- For the personas and roles that interact with these tables, see FSO Disputes Roles and Personas.
- For how network rules populate reason codes and chargeback fields, see FSO Disputes Content Pack for Card Network Rules.
- For how Reg E and Reg Z SLA fields are enforced, see FSO Disputes Content Pack for US Regulations.
- For Card Data Security tokenization and the Tokenizer Resource Configuration table, see Card Data Security and PCI Compliance.
Have questions about the data model or field behavior? Post them in the FSO Community Forum.
