Install
$ agentstack add skill-arohitu-salesforce-revenue-cloud-skills-enable-advance-configurator ✓ scanned · ✓ verified — works with Claude Code, Cursor, and more.
Security review
✓ PassedNo issues found. Passed automated security review. · v0.1.0 How review works →
- ✓ Prompt-injection patterns
- ✓ Secret / credential exfiltration
- ✓ Dangerous shell & filesystem operations
- ✓ Untrusted network calls
- ✓ Known-malicious package signatures
What it can access
- ✓ Network access No
- ✓ Filesystem access No
- ✓ Shell / process execution No
- ✓ Environment & secrets No
- ✓ Dynamic code execution No
From automated source analysis of v0.1.0. “Used” means the capability is present in the source — more access means more to trust, not that it’s unsafe.
About
Enable Advance Configurator
Use this skill to enable and validate Salesforce Revenue Cloud Advanced Configurator (Constraint Rules Engine) in a connected org with a safe, stepwise workflow.
This skill combines:
- automation via
sfand bundled scripts - retrieve-then-update for existing org metadata (settings, layouts)
- guarded deploy and Tooling API creation steps (
--dry-runfirst, then explicit--confirm) - explicit user confirmation before irreversible steps
Source of truth: this skill and references/setup-workflow.md.
Platform note
Bundled scripts are bash. On Windows, run them via Git Bash or WSL. The agent may also run equivalent sf commands directly in PowerShell when scripts are unavailable.
Default workflow
- Confirm the target org alias. If missing, ask for it. Only use the Salesforce CLI default org after saying that clearly.
- Run prereq checks:
bash scripts/check-advanced-configurator-prereqs.sh --target-org
- Assign the designer permission set if not already assigned:
sf org assign permset --name AdvancedConfiguratorDesigner --target-org
- Generate deployable metadata (fields, triggers, optional FLS permission set):
bash scripts/prepare-advanced-configurator-source.sh --out-dir build/adv-config-source
- Validate deployment in dry-run mode:
bash scripts/deploy-advanced-configurator-source.sh --target-org --source-dir build/adv-config-source/force-app/main/default --dry-run
- Deploy fields/triggers/FLS only after explicit user confirmation:
bash scripts/deploy-advanced-configurator-source.sh --target-org --source-dir build/adv-config-source/force-app/main/default --confirm
- Enable Revenue Settings via metadata (retrieve from org first, then update):
bash scripts/enable-advanced-configurator-settings.sh --target-org --dry-runbash scripts/enable-advanced-configurator-settings.sh --target-org --confirm- If metadata deploy fails, ask the user to flip toggles manually in Setup > Revenue Settings.
- Create or reuse
TransactionProcessingTypewithRuleEngine=AdvancedConfigurator(only after step 7 enables transaction processing):
bash scripts/create-advanced-configurator-tpt.sh --target-org --dry-runbash scripts/create-advanced-configurator-tpt.sh --target-org --confirm
- Update Quote and Order layouts with Sales Transaction Type field (retrieve-then-update):
bash scripts/update-quote-order-layouts.sh --target-org --dry-runbash scripts/update-quote-order-layouts.sh --target-org --confirm
- Update the Sales Transaction context definition with constraint attributes and entity mappings (last setup step; after custom fields, settings, TPT, and layouts):
- Ask the user for the context definition API name (e.g.
RLM_SalesTransactionContext). bash scripts/update-context-definition-constraints.sh --target-org --context-definition-name --dry-runbash scripts/update-context-definition-constraints.sh --target-org --context-definition-name --confirm- Whether deployment succeeds or fails, ask the user to open the context definition in Setup and manually verify the attributes, entity mappings, and activation. If deployment failed, ask the user to complete the changes manually.
- Remind user that AssetToSalesTransactionMapping remains a manual checkpoint.
- Run final verification and report what is done vs still manual:
bash scripts/verify-advanced-configurator-setup.sh --target-org --context-definition-name
Retrieve-then-update rules
- Always retrieve existing
IndustriesConstraints,RevenueManagement, layouts, and context definitions from the org before editing. - Never deploy bulk
Settingsretrieve output — deploy only the two changed settings files. - Deploy only the single context definition file after surgical constraint updates — never redeploy noisy bulk retrieve output.
- Generate fresh metadata only for net-new artifacts (custom fields, triggers).
Manual checkpoints (never skip)
- Require explicit user confirmation before live deploy, settings deploy, TPT creation, context definition deploy, and layout deploy.
- Remind user that enabling transaction processing (
enableTransactionProcessor) is irreversible. - Remind user that selecting a default transaction processing type can be irreversible after enablement.
- If metadata settings deploy fails, fall back to manual Setup > Revenue Settings toggles and wait for user confirmation.
Available scripts
scripts/check-advanced-configurator-prereqs.sh: validates CLI/auth, object support, and current org readiness.scripts/prepare-advanced-configurator-source.sh: generates deployable metadata and Apex triggers into a local output folder.scripts/deploy-advanced-configurator-source.sh: deploys generated metadata with dry-run and confirmation gates.scripts/enable-advanced-configurator-settings.sh: retrieve-update-deployIndustriesConstraintsandRevenueManagementsettings.scripts/create-advanced-configurator-tpt.sh: creates or reuses anAdvancedConfiguratortransaction processing type using Tooling API.scripts/update-context-definition-constraints.sh: retrieve-update-deploy constraint attributes and entity mappings on a context definition.scripts/update-quote-order-layouts.sh: retrieve-update-deploy Quote and Order layouts withSalesTransactionTypeId.scripts/verify-advanced-configurator-setup.sh: post-setup verification and manual reminder output.
All scripts support --help. Keep outputs structured and avoid exposing access tokens in responses.
When to read references
- Read
references/setup-workflow.mdbefore first run, and whenever the user asks why each step is required. - Read
references/context-definition-changes.mdfor exact XML blocks and manual checkpoints. - Re-check
references/setup-workflow.mdif behavior in the org differs from the expected setup sequence.
Partial automation / manual checkpoints
Context definition updates are partially automated:
- Automated: retrieve context definition by API name, add
ConstraintEngineNodeStatus__c/AssetConstraintEngineNodeStatus__cattributes, and Quote/Order/Asset entity mappings (idempotent, surgical deploy). - Manual:
AssetToSalesTransactionMappingcross-attribute mapping (org-specific). - Manual: activate the context definition version in Setup when required.
- Always: after attempting context definition deploy (success or failure), ask the user to manually open Setup and verify attributes, mappings, and activation.
Ask the user for the context definition API name before running the context definition script. Do not claim setup is fully complete until the user confirms manual verification and any required manual checkpoints.
Boundaries
- Do not run live deployment or Tooling API mutation without explicit user confirmation.
- Do not create TPT before
enableTransactionProcessoris enabled (TPT Tooling API is unavailable until then). - Do not include bearer tokens in logs, files, or final answers.
Source & license
This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.
- Author: arohitu
- Source: arohitu/salesforce-revenue-cloud-skills
- License: MIT
Install and usage instructions live in the source repository linked above.
Reviews
No reviews yet — be the first.
Write a review
Versions
- v0.1.0 Imported from the upstream source.