The Salesforce Case object is the standard record for a customer issue, question, request, or problem. It is central to Salesforce case management and can connect customer context, service processes, communications, files, entitlements, milestones, and integrations in one record.

This guide is for administrators, developers, solution architects, and integration teams that need to understand how the object is structured and how to work with it safely.

Quick answer: The Case object stores the operational state of a support request. Use fields such as Status, Priority, Origin, AccountId, ContactId, and OwnerId for workflow and reporting. Use child and related objects for comments, history, milestones, activities, emails, and Files. Integrations should respect sharing, CRUD permissions, field-level security, picklist configuration, and automation already active in the Salesforce organization.

1. What is the Salesforce Case object?

In Salesforce’s data model, an object is similar to a database table and a field is similar to a column.

Each Case record represents one service issue and has a unique Salesforce ID.

The standard API name is:

Case


Case records commonly support:

• Customer support
• Internal service desks
• Partner requests
• Product issue reporting
• Warranty or service requests
• Escalations
• Complaint management
• Public-sector or constituent service processes

The Case object is customizable.

The Case object is the technical foundation of a broader operational process. Our Salesforce Case Management guide explains how intake, routing, investigation, escalation, communication, and resolution work across the full Case lifecycle.

Organizations can add:

• Custom fields
• Validation rules
• Record types
• Page layouts
• Flows
• Apex
• Triggers
• Integrations

That flexibility means an integration should never assume that two Salesforce organizations use exactly the same fields, record types, validation rules, or picklist values.

2. Core Salesforce Case fields

The Case object contains many standard fields. The following are among the most commonly used.

Identity and description fields

Use Id for API relationships.

Use CaseNumber for user communication and display.

A Case Number is not a substitute for authorization.

Status and classification fields

Status, Priority, Origin, Type, and Reason are picklists whose values may be customized.

Query Salesforce metadata or use organization-specific configuration rather than hard-coding values copied from another Salesforce environment.

Customer and relationship fields

Not every Case must have both an Account and a Contact.

Anonymous, consumer, public-sector, or external intake models may use supplied-contact fields or custom identity models.

Ownership and timing fields

OwnerId can reference either a user or a queue.

Integrations that display ownership should be prepared for both possibilities.

Supplied contact fields

Cases created through unauthenticated or email-based channels may use fields such as:

• SuppliedName
• SuppliedEmail
• SuppliedPhone
• SuppliedCompany

These fields contain submitted information.

They should not automatically be treated as a verified Salesforce Contact identity.

3. Key Salesforce Case relationships

A Salesforce Case becomes useful through its relationships with other records.

Account and Contact

The Account identifies the customer organization.

The Contact identifies the person associated with the issue.

These relationships give agents access to broader customer history and context.

Owner and queue

The owner identifies the user or queue currently responsible for the Case.

Ownership can change through:

• Assignment rules
• Flow
• Omni-Channel
• Manual reassignment
• Custom Apex
• Integrations

Parent and child Cases

ParentId can create a hierarchy between Cases.

Common uses include:

• One master Case for a widespread incident
• A parent Case with several location-specific child Cases
• A complex request divided into team-owned subcases

Define how status, communication, and closure should work across the hierarchy.

Creating a relationship alone does not automatically synchronize the related Case records.

CaseComment

CaseComment stores public or private comments related to the Case.

This relationship is useful for:

• Customer updates
• Internal notes
• Troubleshooting observations
• Escalation context

Permissions, external visibility, notifications, and API editing behavior require careful review.

Comment visibility and notification behavior require careful configuration. See our complete guide to Salesforce Case Comments for setup, API behavior, and public-versus-private best practices.

CaseHistory

CaseHistory records changes to fields configured for history tracking.

It can support:

• Auditing
• Process analysis
• Change reporting
• Escalation review

History tracking must be enabled for the relevant fields and has retention and reporting considerations.

CaseMilestone and Entitlement

Entitlements and milestones support service-level processes.

The available fields and related records depend on the Salesforce configuration, licenses, and service process.

CaseTeamMember

Case teams can give additional users defined roles on a Case.

Use Case teams when collaboration requires more structure than a single owner.

EmailMessage, activities, and communications

Email and activities provide communication and work history.

The exact object relationships depend on the Salesforce features and configuration in use.

Salesforce Files

Modern Salesforce Files are not stored directly in a field on the Case object.

A Case is linked to a ContentDocument through ContentDocumentLink.

Case.Id = ContentDocumentLink.LinkedEntityId


This is why a query against the legacy Attachment object does not return all files uploaded through Lightning Experience.

Salesforce Files use a different data model from legacy Attachments. Our Salesforce Attachment Object vs. Files guide explains the relevant objects, relationships, APIs, and migration considerations.

4. Useful SOQL queries for the Case object

The following examples are intentionally generic.

Replace IDs, fields, and picklist values with values from the target Salesforce organization.

Query a Case with Account and Contact

SELECT Id,
      CaseNumber,
      Subject,
      Description,
      Status,
      Priority,
      Origin,
      OwnerId,
      AccountId,
      Account.Name,
      ContactId,
      Contact.Name,
      Contact.Email,
      CreatedDate,
      LastModifiedDate
FROM Case
WHERE Id = '500XXXXXXXXXXXX'


Query open high-priority Cases

SELECT Id,
      CaseNumber,
      Subject,
      Status,
      Priority,
      OwnerId,
      CreatedDate
FROM Case
WHERE IsClosed = FALSE
 AND Priority = 'High'
ORDER BY CreatedDate ASC


Use the actual Priority value configured in the target organization.

Query Cases in a queue

SELECT Id,
      CaseNumber,
      Subject,
      Status,
      OwnerId
FROM Case
WHERE OwnerId = '00GXXXXXXXXXXXX'
ORDER BY CreatedDate ASC


Salesforce queue and public-group IDs commonly begin with 00G.

However, integrations should resolve and validate the intended Group record rather than relying only on an ID prefix.

Query a Case with recent comments

SELECT Id,
      CaseNumber,
      Subject,
      Status,
      (SELECT Id,
              CommentBody,
              IsPublished,
              CreatedById,
              CreatedDate
       FROM CaseComments
       ORDER BY CreatedDate DESC
       LIMIT 10)
FROM Case
WHERE Id = '500XXXXXXXXXXXX'


When building a reusable integration, confirm the child relationship name through the target organization’s describe metadata.

Query Files linked to a Case

SELECT ContentDocumentId,
      ContentDocument.Title,
      ContentDocument.FileType,
      ContentDocument.LatestPublishedVersionId,
      ShareType,
      Visibility
FROM ContentDocumentLink
WHERE LinkedEntityId = '500XXXXXXXXXXXX'


Incremental synchronization query

SELECT Id,
      CaseNumber,
      Status,
      Priority,
      OwnerId,
      SystemModstamp
FROM Case
WHERE SystemModstamp > 2026-07-14T00:00:00Z
ORDER BY SystemModstamp ASC


For production synchronization:

• Use a supported incremental strategy.
• Account for deletes and merges where relevant.
• Design for pagination.
• Handle retries.
• Prevent duplicate processing.
• Store durable synchronization checkpoints.
• Monitor incomplete or failed sync runs.

5. Creating a Case through the REST API

A common Salesforce REST API endpoint is:

POST /services/data/v67.0/sobjects/Case


Example JSON request:

{
 "Subject": "Checkout page does not complete payment",
 "Description": "Customer receives an error after selecting Save Card.",
 "Origin": "Web",
 "Status": "New",
 "Priority": "High",
 "AccountId": "001XXXXXXXXXXXX",
 "ContactId": "003XXXXXXXXXXXX"
}


Salesforce returns the created record ID when the request succeeds.

Important creation considerations

Before creating a Case through the API, confirm that:

• The integration user has create access to the Case object.
• The integration user has field access to every submitted field.
• Picklist values are valid for the selected record type and support process.
• Required standard and custom fields are included.
• Validation rules have been reviewed.
• Assignment behavior is understood.
• Flow and Apex automation have been tested.
• Duplicate logic has been reviewed.
• The Account and Contact relationship is valid.
• Any custom business logic is satisfied.

Assignment rules do not necessarily run automatically for every API pattern.

Use the documented headers or process required for the selected Salesforce API.

Test the complete transaction in a sandbox using the intended integration identity.

6. Updating a Salesforce Case

A REST API update commonly uses:

PATCH /services/data/v67.0/sobjects/Case/500XXXXXXXXXXXX


Example JSON request:

{
 "Status": "In Progress",
 "Priority": "Medium"
}


The update may trigger:

• Routing
• Notifications
• Milestones
• Flow
• Apex
• Escalation logic
• External integrations
• Platform events

Avoid sending unchanged fields unless there is a specific reason.

Unnecessary updates create audit noise and may activate automation.

For concurrency-sensitive workflows, define how the integration detects and handles a record changed by an agent after the integration originally read it.

7. Creating a Case Comment

A Case Comment can be created through the API or Apex.

Example API payload:

{
 "ParentId": "500XXXXXXXXXXXX",
 "CommentBody": "We reproduced the issue and are testing a fix.",
 "IsPublished": true
}


Treat IsPublished carefully.

A public comment may become visible to an eligible external user through the configured customer experience.

Review the complete Salesforce Case Comments guide for visibility and notification considerations

8. Adding a File to a Case

The modern Salesforce pattern is to create a ContentVersion and relate the resulting File to the Case.

A simplified Apex example:

ContentVersion fileVersion = new ContentVersion(
   Title = 'Redacted error log',
   PathOnClient = 'error-log.txt',
   VersionData = logBlob,
   FirstPublishLocationId = caseId
);

insert fileVersion;


For integrations, use a supported multipart file-upload API.

Validate the file and confirm that the resulting ContentDocumentLink has the intended visibility.

Review the complete Salesforce file-upload guide for UI, Flow, Lightning Web Component, API, and Data Loader methods.

9. Adding video context to a Case

There are three common ways to add video context to a Salesforce Case.

Upload the video as a Salesforce File

This can work for an occasional recording.

Review:

• File size
• Salesforce storage consumption
• Browser playback
• Sharing
• Retention
• External access
• Accessibility
• Download restrictions

Store a video URL in a field or related record

This is simple, but the integration must manage:

• Access
• Link lifetime
• Video title
• Thumbnail
• Processing status
• Retention
• The relationship between the video and the Case

Do not store a publicly accessible video URL in Salesforce unless public access has been intentionally approved.

Use a video workflow integration

Videolink is designed to add video context to Salesforce records.

Agents can:

• Record an explanation
• Request a video from the customer
• Keep the recording connected to the Case workflow
• Share visual context with escalation teams

The customer can show the issue without scheduling a call.

Depending on the configuration, Videolink can also provide:

• Captions
• AI summaries
• Access controls
• Flexible hosting
• Storage options
• Secure playback

A useful integration data model may capture:

• Salesforce Case ID
• Videolink video ID
• Secure video URL
• Video title
• Request status
• Requesting agent
• Customer submission timestamp
• Transcript availability
• Summary availability
• Access status
• Retention status

Video capture is one part of the wider service technology stack. Our overview of Salesforce customer support software covers tools for visual issue capture, telephony, automation, knowledge management, document generation, and reporting.

10. Case automation and integrations

Before writing custom code, inventory the automation already connected to the Case object.

This may include:

• Assignment rules
• Auto-response rules
• Escalation rules
• Record-triggered Flow
• Screen Flow
• Apex triggers
• Entitlements
• Milestones
• Omni-Channel routing
• Email-to-Case
• Web-to-Case
• Managed packages
• Platform events
• Outbound integrations

A technically valid API update can still produce an unexpected business result if it activates existing automation.

Design integrations around business events

Useful business events include:

• Case created
• Ownership changed
• Customer replied
• Additional evidence received
• Video request sent
• Video submitted
• Case escalated
• Case resolved
• Case reopened

Store idempotency keys or external identifiers where appropriate.

This helps prevent retries from creating duplicate:

• Cases
• Comments
• Files
• Video records
• Tasks
• Notifications

11. Security best practices for the Case object

Use a dedicated integration user

Avoid sharing a human administrator account.

Grant only the licenses, permissions, objects, fields, and records required by the integration.

Respect sharing and field security

Apex system context and broad API permissions can create access beyond what a normal agent sees.

Use Salesforce-recommended enforcement patterns and test with realistic user permissions.

Do not use the Case ID as authorization

A Salesforce ID identifies a record.

It does not prove that a public visitor or external application is authorized to access or update that record.

Protect public comments and Files

A visibility mistake can expose:

• Internal notes
• Customer evidence
• Attachments
• Screenshots
• Video recordings
• Personal information

Test public and private comments, Experience Cloud sharing, and File visibility as separate concerns.

Minimize sensitive data

Do not store:

• Passwords
• Authentication tokens
• Private keys
• Prohibited payment data
• Restricted personal data
• Unredacted secrets
• Sensitive information prohibited by policy

Apply this rule to:

• Case descriptions
• Comments
• Logs
• Attachments
• Files
• Screen recordings
• Video transcripts

Provide redaction guidance for screenshots and video recordings.

Log integrations without logging secrets

Record:

• Request IDs
• Salesforce record IDs
• Integration status
• HTTP status codes
• Failure reasons
• Processing timestamps

Avoid logging:

• OAuth tokens
• Guest-upload tokens
• Passwords
• Unredacted sensitive payloads
• Publicly reusable video links

Unauthenticated uploads need additional controls because a Salesforce record ID is not proof of authorization. Read our guide to allowing guest users to upload files in Salesforce safely.

12. Salesforce Case object implementation checklist

Before releasing a Salesforce Case integration, confirm that:

• Standard fields are discovered from the target organization.
• Custom fields are discovered from the target organization.
• Record types are supported.
• Valid picklist values are handled.
• Required fields are known.
• Validation rules are understood.
• Assignment behavior is tested.
• Escalation behavior is tested.
• API calls use the correct supported version.
• CRUD permissions are reviewed.
• Field-level security is reviewed.
• Record access is reviewed.
• Automation side effects are documented.
• Duplicate behavior is controlled.
• Retry behavior is controlled.
• Case Comments have the intended public or private visibility.
• Files use the modern Salesforce Files model unless a legacy requirement exists.
• Customer video URLs and permissions are secure.
• Data-retention workflows include related evidence.
• Deletion workflows include related evidence.
• Monitoring can trace a customer request across systems.

13. Frequently asked questions

What is the API name of the Salesforce Case object?

The standard API name is Case.

What is the difference between Case Id and CaseNumber?

Id is the unique Salesforce record identifier used in relationships and APIs.

CaseNumber is the human-readable auto-number commonly shown to agents and customers.

Can a Case be owned by a queue?

Yes.

OwnerId can reference a user or a queue, depending on the Salesforce organization’s case-management process.

How are files related to a Case?

Modern Salesforce Files are linked through ContentDocumentLink, where LinkedEntityId is the Case ID.

Legacy files may exist as Attachment records with ParentId set to the Case ID.

How are Case Comments related to a Case?

Each CaseComment has a ParentId that references the Case.

IsPublished indicates whether the comment is public or private.

Can a customer submit video to a Salesforce Case?

Yes.

A customer can upload a video through a secure file workflow or use a video-request integration.

Videolink lets an agent request a customer recording and keep the video context associated with the Salesforce workflow.

Which Salesforce API version should I use?

Use a supported API version that has been tested with your integration and update plan.

This article was reviewed in the context of Summer ’26 and API version 67.0, but your package or integration may intentionally use another supported version.

Sources and further reading

Salesforce Developers, Case Object Reference

Salesforce Developers, Case Field Reference

Salesforce Developers, CaseComment Object Reference

Salesforce Developers, ContentDocumentLink Object Reference

Salesforce, Understanding Salesforce Files

Salesforce, Case Management Best Practice Guide

Videolink, Salesforce Integration

Videolink, AI Captions and Summaries