AgentStack
SKILL verified MIT Self-run

Enable Advance Configurator

skill-arohitu-salesforce-revenue-cloud-skills-enable-advance-configurator · by arohitu

Enable and set up Salesforce Revenue Cloud Advanced Configurator (Constraint Rules Engine) in a connected org. Use when the user asks to enable Advanced Configurator, configure Constraint Rules Engine, create TransactionProcessingType records with RuleEngine=AdvancedConfigurator, deploy ConstraintEngineNodeStatus fields and triggers, update Sales Transaction context definitions, enable Revenue Se…

No reviews yet
0 installs
0 views
view→install

Install

$ agentstack add skill-arohitu-salesforce-revenue-cloud-skills-enable-advance-configurator

✓ scanned · ✓ verified — works with Claude Code, Cursor, and more.

Security review

✓ Passed

No 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.

Are you the author of Enable Advance Configurator? Claim this listing to set pricing, connect Stripe payouts, and keep 70% of every sale.
Sign up to claim

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 sf and bundled scripts
  • retrieve-then-update for existing org metadata (settings, layouts)
  • guarded deploy and Tooling API creation steps (--dry-run first, 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

  1. Confirm the target org alias. If missing, ask for it. Only use the Salesforce CLI default org after saying that clearly.
  2. Run prereq checks:
  • bash scripts/check-advanced-configurator-prereqs.sh --target-org
  1. Assign the designer permission set if not already assigned:
  • sf org assign permset --name AdvancedConfiguratorDesigner --target-org
  1. Generate deployable metadata (fields, triggers, optional FLS permission set):
  • bash scripts/prepare-advanced-configurator-source.sh --out-dir build/adv-config-source
  1. 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
  1. 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
  1. Enable Revenue Settings via metadata (retrieve from org first, then update):
  • bash scripts/enable-advanced-configurator-settings.sh --target-org --dry-run
  • bash scripts/enable-advanced-configurator-settings.sh --target-org --confirm
  • If metadata deploy fails, ask the user to flip toggles manually in Setup > Revenue Settings.
  1. Create or reuse TransactionProcessingType with RuleEngine=AdvancedConfigurator (only after step 7 enables transaction processing):
  • bash scripts/create-advanced-configurator-tpt.sh --target-org --dry-run
  • bash scripts/create-advanced-configurator-tpt.sh --target-org --confirm
  1. Update Quote and Order layouts with Sales Transaction Type field (retrieve-then-update):
  • bash scripts/update-quote-order-layouts.sh --target-org --dry-run
  • bash scripts/update-quote-order-layouts.sh --target-org --confirm
  1. 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-run
  • bash 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.
  1. 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 Settings retrieve 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-deploy IndustriesConstraints and RevenueManagement settings.
  • scripts/create-advanced-configurator-tpt.sh: creates or reuses an AdvancedConfigurator transaction 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 with SalesTransactionTypeId.
  • 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.md before first run, and whenever the user asks why each step is required.
  • Read references/context-definition-changes.md for exact XML blocks and manual checkpoints.
  • Re-check references/setup-workflow.md if 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__c attributes, and Quote/Order/Asset entity mappings (idempotent, surgical deploy).
  • Manual: AssetToSalesTransactionMapping cross-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 enableTransactionProcessor is 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.

Install and usage instructions live in the source repository linked above.

Reviews

No reviews yet — be the first.

Versions

  • v0.1.0 Imported from the upstream source.