Use when the user wants to retrieve or update Organization-Wide Default (OWD) sharing settings for Salesforce objects. TRIGGER when: user asks to check current OWD settings, view sharing defaults, change default access levels (Private, Public Read Only, Public Read/Write, Controlled by Parent), conf

Managing Org Wide Defaults Retrieve and update Organization Wide Default (OWD) sharing settings for standard and custom objects in a Salesforce org. OWDs define the baseline level of access users have to records they do not own. Scope In scope : Retrieving current OWD settings, updating internal/external access levels for standard and custom objects Out of scope : Sharing rules, role hierarchy configuration, manual sharing, permission sets, criteria based sharing — delegate to appropriate skills Clarifying Questions Before proceeding, confirm with the user if not already clear: Which object(s) do you want to get or update OWD settings for? What access level do you want to set? (Private, Public Read Only, Public Read/Write, Controlled by Parent) Do you need to change both internal and external access, or just one? Required Inputs Gather or infer before proceeding: Target org : The org alias or username to query/update (use default org if not specified) Object name(s) : Standard object API name (e.g., Account , Contact ) or custom object API name (e.g., Invoice c ) Operation : Get (retrieve current settings) or Update (change access levels) Access levels (for update): Internal access and/or external access values Defaults unless specified: Use the default connected org If only one access level is provided, assume it applies to internal access Workflow All steps are sequential. Do not skip or reorder. Phase 1 — Retrieve Current Settings 1. Query current OWD settings using the Salesforce CLI Tooling API: sf data query query "SELECT QualifiedApiName, InternalSharingModel, ExternalSharingModel FROM EntityDefinition WHERE QualifiedApiName = '<ObjectName '" use tooling api target org <org 2. For retrieving all OWD settings at once: sf data query query "SELECT QualifiedApiName, InternalSharingModel, ExternalSharingModel FROM EntityDefinition WHERE IsCustomizable = true ORDER BY QualifiedApiName" use tooling api target org <org 3. Present results clearly — read references/access levels.md for valid values and display a formatted table to the user. Phase 2 — Update Settings (if requested) 4. Check for immutable/fixed OWD — read references/access levels.md "Immutable / Fixed OWD Objects" section. If the requested change targets a fixed value (e.g., Price Book external OWD), stop immediately and explain to the user that this value is platform fixed and cannot be changed by any means. Do not attempt a deploy. 5. Validate the requested access level — read references/access levels.md to confirm the value is valid for the target object. If the value is not in the allowed set for that object, explain what values are valid and ask the user to choose one. Do not guess alternative values. 6. Retrieve the object metadata using the Metadata API (same command for both standard and custom objects): sf project retrieve start metadata CustomObject:<ObjectName target org <org . This retrieves <ObjectName .object meta.xml containing <sharingModel and <externalSharingModel . See references/metadata api approach.md for the full procedure. 7. Modify the sharing settings — update the <sharingModel (internal access) and/or <externalSharingModel (external access) in the object's .object meta.xml . Read references/metadata api approach.md for details. 8. Pre deploy verification — before deploying, confirm: [ ] External access is not more permissive than internal access [ ] Objects with Master Detail relationships use ControlledByParent [ ] The requested access level is valid for the target object (see references/access levels.md ) [ ] Cross object constraints are satisfied (see "Cross Object Constraints" in references/access levels.md ) [ ] The target field is not listed as immutable/fixed in references/access levels.md 9. Deploy the updated settings: sf project deploy start metadata CustomObject:<ObjectName target org <org . 10. Handle deploy failure (max 2 attempts): If the deploy fails: Read the error message and identify the root cause. If the error indicates the value is invalid or unsupported for the object, stop — report the failure to the user with the exact error message and explain what is and isn't possible. Do not try alternative values unless the user explicitly requests a different valid value. If the error is transient (network timeout, auth expired), retry once . Never attempt more than 2 total deploys for the same change. After 2 failures, report the error, discard local edits ( sf project retrieve start metadata CustomObject:<ObjectName target org <org ), and ask the user how to proceed. 11. Verify the change by re running the query from Phase 1, Step 1. Rules / Constraints Constraint Rationale Objects with Master Detail relationships must use ControlledByParent Platform enforces this — attempting other values fails External access cannot be more permissive than internal access Salesforce rejects configurations where external internal Some objects have immutable/fixed OWD (e.g., Price Book external, User, Activity external) These are platform enforced — explain impossibility upfront, never attempt a deploy Price Book only accepts Use ( ReadSelect ) or No Access ( None ) for internal OWD; external is always None Standard access levels (Private/Read/ReadWrite) are invalid for Price Book Changing OWD to more restrictive triggers sharing recalculation This can take significant time on large orgs — warn the user Custom objects default to Public Read/Write when created Users may not realize the default is permissive For managed package custom objects, use the full API name including namespace prefix (e.g., ns Object c ) Namespace prefixed objects require the prefix in both queries and metadata retrieval Always verify the org connection before querying Prevents confusing error messages Maximum 2 deploy attempts per change Prevents unbounded retry loops — after 2 failures, stop and report to the user Gotchas Issue Resolution INSUFFICIENT ACCESS error when updating User needs Manage Sharing permission or System Administrator profile OWD change appears stuck Sharing recalculation is running — check Setup Sharing Settings for progress Custom object not found in query Use the full API name including c suffix ControlledByParent not available Object has no Master Detail relationship — use Private, Public Read Only, or Public Read/Write External access field not showing External sharing model only appears when external org wide defaults are enabled Query returns no results Object may not be customizable or API name may be incorrect — verify spelling Deploy fails with invalid value for Price Book Price Book only accepts Use / None (internal) and external is fixed at None — do not retry with other values, explain to user Output Expectations Deliverables: For get operations : Formatted table showing object name, internal access level, and external access level For update operations : Confirmation of the change with before/after comparison Cross Skill Integration Need Delegate to Creating sharing rules after restricting OWD platform sharing rules generate skill Deploying metadata changes to another org platform metadata deploy skill Reference File Index File When to read references/access levels.md When validating or explaining OWD access level values references/metadata api approach.md When using Metadata API to update OWD instead of Tooling API examples/get owd output.md To verify formatted output matches expected structure examples/update owd output.md To verify update confirmation matches expected structure

platform-sharing-owd-configure