/platform-dsar-policy-manage

name: platform-dsar-policy-manage
description: "Configure, run, and audit DsarPolicy Right-to-Portability exports end to end: author the data map over a subject's related records, resolve a request's subject (email/name/id) to a root-entity record, run an export against an ACTIVE policy (poll a couple of times, then ask before continuing; download once terminal), and read run history. Use when the user needs to set up, edit, execute, or inspect a DsarPolicy or Right-to-Portability (RTP) export, or audit which personal data a policy does not cover yet. TRIGGER when: the user configures a DsarPolicy or RTP data map, authors DsarPolicyPath or DsarPolicyField metadata, runs or exports a subject's portable data, downloads an RTP export file, reviews DsarPolicy run history, or asks what personal data the policy does not cover yet (coverage gap analysis). DO NOT TRIGGER when: the user wants to erase, delete, or remove a subject's records (RTP is portability export, not erasure — this skill deletes nothing), mask sandbox PII, or deploy unrelated metadata."
metadata:
  version: "1.7"
  domains: ["Platform"]
  minApiVersion: "68.0"
  cliTools:
    - tool: ["python3"]
      semver: ">=3.10.0"
    - tool: ["sf"]
      semver: ">=2.0.0"

platform-dsar-policy-manage: DsarPolicy Right to Portability, end to end

Operate a **`DsarPolicy`** — the metadata driving a **Right-to-Portability (RTP)** export — across its lifecycle: **configure** the tree, **run** an export, **audit** runs. A `DsarPolicy` is a *read/export map*: it names which of a subject's records an export collects. It **never deletes anything**. The value here is **judgment**, not XML plumbing.

> **FIRST LINE OF EVERY RESPONSE — do not narrate the skill.** Your first output token is *work or > the answer*, never a play-by-play. Do **not** open with "This is a coverage-gap audit / Workflow > D…", "Let me read the skill's guide/mechanics…", "Per rule #1…", or "Let me discover the SOR…". > Don't name the workflow, announce which reference files you're about to read, or describe your > method before doing it — just start doing it (call the tool) and, when done, present the result. > This is load-bearing call #8, stated up front because it governs your very first token. A > plain-language sentence about *the user's data/org* is fine; a sentence about *the skill, its > workflows, rules, tools, or files* is not.

Load-bearing calls (get these right or the task fails)

These override any leading phrasing in the request. Read them first, every time. **Call #1 is the literal first action of every task — before you pick a workflow, before any `sf` command.**

1. **Route through the SOR tool FIRST — before any `sf`/endpoint call, no exceptions.** The very first action of *every* task here — including a trivial read-only "does a policy exist / list the policies" lookup — is to scan **this run's available tools** for a capability-routing tool exposing **discover / describe / dispatch** verbs (project-codey / Headless 360 today; any host prefix such as `mcp__<host>__discover`; **match the verb shape, not a fixed name**). If one is present, that is the entry move: `discover → describe → dispatch` the **`DsarPolicyManager`** SOR (owner Privacy Center; `isActive` gates execute/edit/delete) and reject look-alikes (data mask, generic consent, subject *erasure*). Do **not** reach for `sf` first — grabbing `sf` on reflex because the task "looks like a quick lookup" is the top recurring miss, and it is wrong even when it would work. `sf` is the fallback **only** when no routing tool is in reach (checking `sf org list` to see which orgs are authenticated locally is fine — that is a client-side auth check, not a SOR call). Every `sf`/`salesforce-api-context` command shown in the workflows below is the *no-routing-tool* spelling; when the routing tool is present, dispatch the equivalent operation through it instead. Detail: `references/headless-sor.md`. 2. **Export, never erasure.** A run produces an **export file**; it does not erase/redact/delete the subject. If the request frames it as deletion ("remove them", "erase", "clear out"), **correct that first** and never report the subject as erased. Erasure is a separate mechanism — if that's the goal, say so and stop. You may still export if authorization is clear, after correcting the premise. 3. **Do not guess personal data.** Which objects/relationships hold *the subject's* data is the **admin's** classification call. If the request delegates it ("figure out what counts", "wire the whole thing up"), **do not author a guessed tree** — enumerate the decisions the admin must make (roots; per-relationship follow/stop; fields), mark any proposal *pending admin disposition*. An over-broad guess exports other people's records. 4. **Caps are hard — name the cap and stop; don't graph-walk.** Tree caps: **10 children/path, depth 10, 200 nodes**. An unbounded request ("everything", "the whole graph") cannot fit. Do **not** enumerate the object graph to "try" (never finishes, burns the turn). Name the specific cap exceeded and offer a bounded alternative (split policies, prune branches). Never silently truncate. 5. **Poll a couple of times, then ask — don't block on terminal.** The run handle serves status **and** file. An early *getfile* returns `NOT_FOUND` / `"This file isn't ready yet"` — the contract working, not a failure. Poll ≈2–3×; if still not terminal, **stop and ask the user whether to keep polling** — don't loop. A run can sit non-terminal indefinitely on downstream async processing — **platform / Tool Factory territory, not this skill's to diagnose or reach into**; report status in plain terms (**running / completed / errored**) and let the user decide. Never download before terminal. A **failed run can return HTTP 201** — read the **envelope / `RequestStatus`** in the body, not the HTTP code. getfile segmen