using-ui-bundle-salesforce-data

Access Salesforce records from UI bundles via the Data SDK with schema-verified GraphQL.

803|289|Updated Nov 7, 2025
One-click install
npx skills add https://github.com/forcedotcom/sf-skills --skill using-ui-bundle-salesforce-data-forcedotcom
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: using-ui-bundle-salesforce-data
Source: https://github.com/forcedotcom/sf-skills/tree/main/skills/using-ui-bundle-salesforce-data
Command: npx skills add https://github.com/forcedotcom/sf-skills --skill using-ui-bundle-salesforce-data-forcedotcom

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes scripts (resource) components.

What problem does it solve?

This Skill prevents broken or insecure Salesforce record operations in UI bundles by enforcing a single, schema-verified Data SDK approach for both reads and writes.

Core Features & Use Cases

  • Data SDK enforcement: Requires all Salesforce data access to go through @salesforce/sdk-data, handling authentication, CSRF, and base URL resolution.
  • GraphQL-first record operations: Defines when to use sdk.graphql (preferred for record queries/mutations) versus sdk.fetch (for specific REST-like gaps such as UI API metadata, Apex REST, Connect upload config, or Einstein LLM).
  • Schema-verified query generation workflow: Mandates schema.graphql presence, entity/field discovery via scripts/graphql-search.sh, and prohibits guessing names or types.
  • GraphQL safety rules: Requires errors parsing, @optional on record fields, explicit pagination (first + pageInfo), correct mutation wrapping (uiapi(input: { allOrNone: ... })), and strict allowlisting of supported APIs.
  • UI bundle integration guidance: Supports .graphql files with codegen and inline gql for simpler queries, with resilient consuming code patterns (optional chaining and nullish coalescing).

Quick Start

Use this skill to guide your UI bundle so that you only write GraphQL operations after verifying entities and fields with graphql-search, then generate types with graphql:codegen and call the operations through the Data SDK with optional chaining.

Frequently Asked Questions about using-ui-bundle-salesforce-data

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I safely query Salesforce records from a React UI bundle?

To safely query Salesforce records from a React UI bundle, use the Data SDK's `sdk.graphql` method after verifying entities and fields with `schema.graphql` and `graphql-search.sh` to ensure schema-validated type safety.

What is the best way to generate TypeScript types for Salesforce GraphQL queries in UI bundles?

The best way to generate TypeScript types for Salesforce GraphQL queries is using `graphql:codegen` backed by a verified `schema.graphql` file, which processes `.graphql` files to produce strict types for your Data SDK operations.

When should I use sdk.fetch instead of sdk.graphql for Salesforce data access?

Use `sdk.fetch` instead of `sdk.graphql` for specific REST-like gaps such as UI API metadata, Apex REST, Connect upload config, or Einstein LLM operations, while preferring `sdk.graphql` for standard record queries and mutations.

What GraphQL safety rules are required for Salesforce record mutations in UI bundles?

Required GraphQL safety rules for Salesforce record mutations include parsing `errors`, using `@optional` on record fields, specifying explicit pagination with `first` and `pageInfo`, and correctly wrapping mutations with `uiapi(input: { allOrNone: ... })`.

Can I guess Salesforce entity or field names when building GraphQL queries?

No, you cannot guess Salesforce entity or field names when building GraphQL queries; the workflow mandates schema-verified entity and field discovery via `scripts/graphql-search.sh` against a present `schema.graphql` file to prevent brittle operations.

Why do my Salesforce GraphQL queries return unsafe or brittle results in UI bundles?

Salesforce GraphQL queries return unsafe or brittle results in UI bundles when bypassing the Data SDK, guessing field names, or omitting `@optional` and explicit pagination, which the schema-verified Data SDK approach prevents through strict allowlisting and codegen-backed types.