Platform Policy Rule Generate

Authoring Policy Rule Definitions

Gating: requires the EnforceOMatic and PolicyRuleMDAPI org permissions. Min API version: 64.0 (66.0 for conditions using PolicyJsonExpression).

This skill covers the on-disk metadata XML format for authoring policies. Use it whenever a task asks to write a *.policyRuleDefinition or *.policyRuleDefinitionSet file, or ship a metadata package containing them. The runtime side (RuleProvider, hooks) is out of scope.

Eval coverage: This skill is exercised by the team's ADK eval framework, not by tests/evals/ under the skill directory. Five datasets covering the ACCESS / GOVERNANCE / RECORD / TRANSFORM variants live in packages/adk-eval/eval/domains/platform-policy-rule-generate/datasets/.

1. Package Layout

A deployable package always contains:

<fixture>/
  package.xml
  policyRuleDefinitionSets/<setName>.policyRuleDefinitionSet
  policyRuleDefinitions/<ruleName>.policyRuleDefinition

package.xml template (use <version>[ftest]</version> for ftests, 64.0 or higher for real orgs):

<?xml version="1.0" encoding="UTF-8"?>
<Package xmlns="http://soap.sforce.com/2006/04/metadata">
    <types>
        <members>Rule0</members>
        <name>PolicyRuleDefinition</name>
    </types>
    <types>
        <members>Set1</members>
        <name>PolicyRuleDefinitionSet</name>
    </types>
    <version>64.0</version>
</Package>

2. PolicyRuleDefinitionSet Schema

<PolicyRuleDefinitionSet xmlns="http://soap.sforce.com/2006/04/metadata">
    <label>Set1</label>
    <description>Optional free text</description>
    <replicated>false</replicated>             <!-- MinAppVersion 260 -->
    <builderCompatible>true</builderCompatible> <!-- MinAppVersion 262, author-settable -->
    <!-- builderValidated: server-managed — do not set in authored XML -->
</PolicyRuleDefinitionSet>

3. PolicyRuleDefinition — Core Fields

4. Category Decision Tree

Category names a domain (where in the platform's enforcement layers the rule applies). Effect names the action (allow / deny / transform). They are independent except for TRANSFORM.

The only Category × Effect rule the platform validates:

• effect=Transform ⇔ category=TRANSFORM_POLICY_RULE_DEFINITION (bidirectional; mismatched throws INVALIDFORCATEGORY).
• All other categories (ACCESS, GOVERNANCE, RECORD, IDENTIFIED_RECORD) accept either Permit or Forbid.

Note on the platform's auto-fill default: When <category> is omitted from authored XML, the server fills it in from effect: Permit→ACCESS, Forbid→GOVERNANCE, Transform→TRANSFORM. This is a default-fill, not a validation. If you author an explicit category that contradicts this default, it is accepted and persisted as-is.

Picking the category

What kind of policy?
│
├── OLS/FLS allow/deny on tagged or classified resources
│     category = ACCESS_POLICY_RULE_DEFINITION (allow/deny attestation in the access plane)
│              | GOVERNANCE_POLICY_RULE_DEFINITION (governance-audited)
│     effect = Permit | Forbid (chosen independently from category)
│     resourceScopeType = ANY | FIELD | DATASPACE
│     NO <policyRuleResourceDomains>
│     condition: resourcePath=TAG|CLASSIFICATION CONTAINS_ANY <ref>
│     For "objects AND all their fields" → action=TupleRead + OR-of-ENTITYTYPE clause (§7)
│     Note: "Block access to Foo object" → tag Foo with <yourTag>, write rule on tag
│        Do NOT use <resourceDomain>Foo</resourceDomain> — forbidden for ACCESS/GOVERNANCE
│
├── Row-level filter on a DMO/DLO
│     category = RECORD_POLICY_RULE_DEFINITION
│     effect = Permit | Forbid
│     resourceScopeType = RECORD
│     <policyRuleResourceDomains> = the DMO/DLO API name  ← entity targeting allowed here
│
├── Identified-Guest record access
│     NOT authorable via MDAPI — SESSION_CONSUMER_ID is not in RuleContextPathType
│        Must be implemented as a runtime RuleProvider.
│
└── Field masking
      category = TRANSFORM_POLICY_RULE_DEFINITION   ← required by RuleBuilder validator
      effect = Transform                            ← required by RuleBuilder validator
      resourceScopeType = FIELD (structured) or SPAN (unstructured)
      <policyRuleResourceDomains> = the DMO whose field is masked
      <resourceTransform> required (e.g. NULL_RESOURCE_TRANSFORM, LAST_N_CHARS_RESOURCE_TRANSFORM)

ACCESS vs GOVERNANCE — how to choose

Both legally accept Permit and Forbid. Pick by which enforcement layer should record/audit the rule and what the prompt literally asks for:

Important — honor the explicit category in the prompt. If the prompt says "ACCESS policy rule that denies …" or "GOVERNANCE policy rule that permits …", emit exactly that category. Do not silently swap to the auto-fill default just because effect is Forbid (or Permit). The platform accepts both. The agent must not override the user's stated intent.

Scope × category compatibility — any combination outside this matrix throws INVALIDFORCATEGORY: