forcedotcom/sf-skills2 files

Platform Dataspace Access Configure

Use this skill to configure or inspect Salesforce Data Cloud DataSpace access for permission sets. Grants dataspace-level access via MDAPI PermissionSet XML with dataspaceScopes elements, optionally grants object-level access to DMO, DLO, or CIO objects via the Object Access Grants Connect API, and inspects existing scopes via read-only PermissionSet metadata retrieval. TRIGGER when: user needs to create or update a permission set with DataSpace access, grant access to a specific dataspace, list permission sets with access to a DataSpace, configure dataAccessLevel/objectAccessLevel, add RBAC object access grants, or list/remove object access grants for a permission set + DataSpace pair. DO NOT TRIGGER when: the task is a generic permission set without dataspace access (use platform-permission-set-generate), the request is about data ingestion/streams, or the work involves creating dataspaces themselves rather than granting access to them.

Specification
Skill ID
forcedotcom/sf-skills/platform-dataspace-access-configure
Publisher
forcedotcom
Repository
sf-skills
Installs
0
Files
2
Synced
Sep 23, 2026
How to use it

Open any RiverX project, open the Skills panel in the chat, and search for this identifier. The files are fetched from the source repository at install time.

forcedotcom/sf-skills/platform-dataspace-access-configureInstalls these files
  • SKILL.md
  • scripts/inspect-dataspace-scopes.sh

What this skill tells the agent

platform-dataspace-access-configure

Configure DataSpace access in Salesforce Data Cloud using a two-layer model:

  1. DataSpace-level access — grant a PermissionSet access to a DataSpace by embedding a <dataspaceScopes> element in the permission set XML and deploying via MDAPI.
  2. Object-level access (optional) — grant that permission set access to specific DMO / DLO / CIO objects within the DataSpace using the Object Access Grants Connect API.

The MDAPI layer is required to establish the PermissionSet → DataSpace linkage. The Connect API layer is optional and only needed when access should be scoped to specific objects rather than governed entirely by data governance policies.


Decide the Case First

Pick exactly one case from the table below before writing any files. Each case has a different output shape.

CaseUser intentPermission set stateFiles to emit
A. Create new permset with DS access"create a permission set called X with dataspace scope Y"does NOT exist yetpermissionsets/<Name>.permissionset-meta.xml and package.xml
B. Add DS access to existing permset"grant existing permission set X access to dataspace Y"already deployed (may contain other permissions)patched permissionsets/<Name>.permissionset-meta.xml and package.xml — see Case B workflow below
C. Object-level grant only"grant permset X access to object Z (in dataspace Y)" — permset + scope already configuredalready deployed with dataspaceScopesapi-request.json (Connect API body). NO permission set XML, NO package.xml
D. Inspect existing DS access"which permission sets have access to dataspace Y?"anychat/report only. NO deployable files, NO runtime API mutation

Only emit the files listed for the case you picked. Emitting Case A/B files for a Case C prompt (or vice versa) is a correctness failure — extra files change the deployment shape.

Case B — critical: PermissionSet MDAPI deploy is a full metadata replace. Every <objectPermissions>, <fieldPermissions>, <userPermissions>, <tabSettings>, <applicationVisibilities>, <recordTypeVisibilities>, <customPermissions>, <pageAccesses>, <classAccesses>, <customMetadataTypeAccesses>, <customSettingAccesses>, <externalDataSourceAccesses> element you omit from the redeploy is deleted from the org. Before adding <dataspaceScopes> to an existing permset, retrieve the current XML and patch it — do not hand-author from scratch.

Case B workflow

  1. Retrieve the existing permission set: ``bash sf project retrieve start --metadata PermissionSet:<Name> --target-org <alias> ``
  2. Open the retrieved permissionsets/<Name>.permissionset-meta.xml. Keep every element already there.
  3. Insert the <dataspaceScopes> block for the target DataSpace (element order in the file does not matter for MDAPI). If the file already has a <dataspaceScopes> block for this same DataSpace, replace only that block. Leave every <dataspaceScopes> block for other DataSpaces untouched — one block per DataSpace. For a requested scope removal, remove only the matching block and deploy; omitting the block revokes that DataSpace grant. Verify by retrieving the PermissionSet and confirming the matching <dataspaceScopes> block is absent.
  4. Write package.xml listing the permset in <members>.
  5. Redeploy with sf project deploy start.

When This Skill Owns the Task

Trigger this skill when the user wants to:

  • Create a permission set that grants access to a Data Cloud DataSpace
  • Add or modify dataspaceScopes on an existing permission set
  • Grant a permission set access to specific DMO / DLO / CIO objects in a DataSpace
  • List which permission sets have a DataSpace scope and inspect its access levels
  • Configure dataAccessLevel and objectAccessLevel for a DataSpace scope
  • List or remove object access grants for a permission set + DataSpace pair

Delegate elsewhere when:

  • The permission set has no DataSpace access at all → platform-permission-set-generate

Layer 1 — DataSpace-Level Access (MDAPI)

Embed a <dataspaceScopes> element inside the PermissionSet XML. Deploy with MDAPI.

<?xml version="1.0" encoding="UTF-8"?>
<PermissionSet xmlns="http://soap.sforce.com/2006/04/metadata">
    <label>Data Cloud Analyst</label>
    <description>Data cloud analyst access to the default dataspace</description>
    <hasActivationRequired>false</hasActivationRequired>
    <dataspaceScopes>
        <dataspaceScope>default</dataspaceScope>
        <dataAccessLevel>ALL</dataAccessLevel>
        <objectAccessLevel>BY_POLICY</objectAccessLevel>
    </dataspaceScopes>
</PermissionSet>

Element Rules

ElementRequiredValid ValuesPurpose
<dataspaceScopes>yesparent element (plural)Container for a single dataspace scope grant
<dataspaceScope>yesDataSpace API name (e.g. default)Which DataSpace this grant is for
<dataAccessLevel>yesNONE, CONTROLLED_BY_PARENT, ALLRow-level data access within the DataSpace
<objectAccessLevel>yesBY_POLICY, ALL_IN_DATASPACEObject-level access. BY_POLICY defers to data governance policies. ALL_IN_DATASPACE is only allowed when dataAccessLevel is CONTROLLED_BY_PARENT

Common Mistakes

  • Wrong parent name — using <dataspaceScopeAccess> instead of <dataspaceScopes>. Deployment fails silently or with cryptic errors.
  • Wrong child name — using <dataspaceScopeName> instead of <dataspaceScope>.
  • Wrong enum values — ViewAllRows / Read / OWNER / EDIT are not valid. Use NONE, CONTROLLED_BY_PARENT, or ALL for dataAccessLevel; use BY_POLICY or ALL_IN_DATASPACE for objectAccessLevel. See Element Rules table for allowed combinations. Deployment error -379999659 means invalid enum.
  • Multiple scopes in one element — <dataspaceScopes> grants access to exactly one DataSpace. To grant access to multiple, add multiple <dataspaceScopes> blocks.

Package Layout (Case A and Case B)

A deployable bundle for Layer 1 always contains both files:

<output-root>/
  package.xml
  permissionsets/<Name>.permissionset-meta.xml

package.xml (required — list every permission set being deployed in <members>):

<?xml version="1.0" encoding="UTF-8"?>
<Package xmlns="http://soap.sforce.com/2006/04/metadata">
    <types>
        <members>Data_Cloud_Analyst</members>
        <name>PermissionSet</name>
    </types>
    <version>67.0</version>
</Package>

Deploy:

sf project deploy start --source-dir force-app/main/default/permissionsets/ --target-org <alias>

Read-Only DataSpace Scope Inspection — Case D

Use Case D when the user asks which permission sets have access to a DataSpace, or asks to inspect dataAccessLevel and objectAccessLevel without making a change.

Never query `DataspaceScope` or `DataspaceScopeAccess` with SOQL. Those objects are not a supported query surface for this relationship. Do not try SOQL as discovery, fallback, or troubleshooting.

  1. Retrieve PermissionSet metadata into an isolated temporary local project and output directory. Do not retrieve into the user's existing metadata tree. Save the skill repository path first (as an absolute path if possible): ``bash REPO_ROOT="<absolute/path/to/sf-skills-internal>" # or $(pwd) if you're in the repo root WORK_DIR=$(mktemp -d) sf project generate --name dataspace-scope-inspection --output-dir "$WORK_DIR" cd "$WORK_DIR/dataspace-scope-inspection" sf project retrieve start --json \ --metadata "PermissionSet:*" --target-org <alias> \ --output-dir "$WORK_DIR/retrieved" ` Inspect the JSON result before continuing. A nonzero command status, a failed result.status, warnings, or an unexpectedly low result.fileProperties`

More from forcedotcom

Use this skill in a project

Open any RiverX project, search the Skills panel for forcedotcom/sf-skills/platform-dataspace-access-configure, and install it in one click.

Use this skill