# Automate CRM Lead Capture and Routing in a Sandbox

Amo ID: AMO-P-000342
Version: 1.0.0
Public URL: https://amo.ng/prompts/automate-crm-lead-capture-routing-sandbox

Summary: Implement and verify CRM lead capture, consent, deduplication, qualification, routing, and SLA behavior in an authorized sandbox using synthetic test leads and disabled production activation.

Use this for: Use this for implementing a bounded CRM lead-capture and routing workflow in an authorized sandbox, with synthetic test evidence and production activation kept disabled.

Category: Automation
Tool: Codex
Difficulty: Expert
Prompt type: crm automation

## Best Use Cases

1. Implementing an approved website-form to CRM lead workflow in a sandbox
2. Configuring deterministic qualification, territory, and round-robin routing
3. Testing consent, duplicate, fallback-owner, retry, and SLA behavior
4. Preparing a CRM automation for RevOps and privacy review before activation

## Prompt Body

Implement and verify the approved CRM lead-capture and routing workflow in an explicitly authorized sandbox, editable configuration export, or other non-production environment. Make actual configuration or repository changes only when that environment and the permitted change boundary are available. Keep production activation disabled.

## Required inputs

Approved capture fields, types, required and optional rules, identifiers, source and campaign fields, and validation behavior:
{{approved_capture_schema}}

CRM and form sandbox details, editable workflow or configuration export, repository context, connector and API documentation, safe test capabilities, and permitted commands or actions:
{{sandbox_and_integration_context}}

Approved qualification criteria, territory logic, queues, owner availability, round-robin rules, fallback assignment, business hours, SLA definitions, and exception owners:
{{qualification_routing_and_sla_rules}}

Approved consent states, data-minimization rules, retention, attribution protections, restricted fields, privacy requirements, and review owners:
{{consent_and_data_handling_requirements}}

Acceptance criteria, allowed systems and records, prohibited actions, synthetic test scenarios, rollback requirements, reviewers, and activation authority:
{{acceptance_criteria_and_authorized_scope}}

## Evidence and assumption rules

- Distinguish supplied rule, observed sandbox or configuration evidence, inference, assumption, conflict, missing information, and execution evidence. Cite configuration objects, field IDs, rule versions, workflow steps, test records, run IDs, and logs where available.
- Treat the approved schema, routing rules, consent requirements, and SLA contract as authoritative inputs. Do not silently resolve conflicts between them. Mark dependent configuration Blocked and identify the responsible owner.
- Inspect the editable export, repository, or authorized sandbox before changing it. Record the exact environment and confirm it is non-production. Preserve unrelated configuration and repository changes. Do not reformat, overwrite, stage, commit, discard, enable, or publish anything outside scope.
- Do not invent CRM fields, API capabilities, connector behavior, owner availability, territory rules, consent status, attribution, records, run results, credentials, or approvals. Documentation is not execution evidence.
- Use only synthetic test leads containing no real names, email addresses, phone numbers, company data, or hidden production identifiers. Never request, paste, reproduce, log, or retain passwords, API keys, tokens, private keys, connection strings, authentication headers, or live webhook secrets. Record only credential-reference and access-status information.

## Authorization boundary

Proceed only when an authorized sandbox, editable workflow export, or repository-backed configuration is available. Change only the approved form, mapping, workflow, routing, test, and local configuration artifacts. Ask before installing dependencies, altering connector permissions, creating credentials, changing schemas, making external calls, or executing an action with irreversible side effects.

Do not use or alter real leads, change production ownership rules, send customer-visible messages, activate production automation, modify live consent or attribution records, replay production events, bulk-update records, grant access, or publish configuration. Keep outbound notifications, sales sequences, advertising audiences, and production webhooks disabled or replaced by approved test sinks. If neither authorized sandbox access nor an editable configuration or export exists, stop with a blocked handoff rather than producing a fictional implementation.

## Implementation method

1. Establish the workflow contract. Map every approved capture field through validation, normalization, identity matching, consent treatment, qualification, routing, SLA calculation, destination field, failure state, and owner. Give each rule a stable ID and identify unresolved conflicts or unavailable platform capabilities.
2. Inspect the non-production implementation. Confirm the environment marker, workflow version, trigger, form or webhook contract, CRM objects and fields, matching keys, connector permissions, routing mechanisms, queues, calendars, retry settings, logs, alerts, test facilities, and existing disablement or rollback controls. Do not infer parity with production.
3. Present a concise implementation checkpoint. List the exact artifacts or sandbox objects expected to change, rules covered, synthetic test records, prohibited side effects, verification steps, risks, and recovery path. Ask only questions that block safe implementation.
4. Implement capture validation and mapping. Enforce approved field types, lengths, required states, enumerations, normalization, and rejection or quarantine behavior. Map only approved fields. Preserve source, campaign, and attribution values according to the supplied rules. Never infer consent from form submission or populate an unknown value as affirmative consent.
5. Implement identity and deduplication. Use the approved stable identifiers, normalization, match precedence, time window, survivorship behavior, and no-merge exceptions. Make repeated submissions idempotent where supported. Route uncertain matches to the approved review state rather than merging or overwriting records.
6. Implement qualification and routing. Encode only supplied qualification, territory, segment, queue, and round-robin rules. Handle no eligible owner, absent or inactive owner, capacity limits, territory conflicts, missing fields, and manual exceptions. Record the route reason and rule version where supported. Do not allow model confidence or an invented rule to assign a consequential lead.
7. Implement SLA behavior. Use the approved start event, pause and stop events, business calendar, timezone, target, reassignment behavior, breach state, and fallback owner. Keep calculated deadlines traceable to their inputs. Do not treat sandbox timing as production SLA performance.
8. Implement reliability controls. Define idempotency keys, duplicate-event handling, retry eligibility, retry limits, backoff, timeout, partial-success state, dead-letter or manual-review path, and reconciliation. A failed trigger is not proof that no CRM record was created. Check authoritative sandbox state before replay.
9. Keep communications and activation disabled. Route notification steps to approved test sinks or disable them. Ensure no production webhook, sequence, campaign, sales message, or customer-visible action can run. Record the disabled state as evidence.
10. Test with synthetic leads. Cover valid capture, invalid types, missing required fields, explicit consent states, restricted data, duplicate and near-duplicate submissions, repeated delivery, conflicting attribution, qualification boundaries, each territory, round-robin sequence, owner absence, no eligible owner, business-hours edges, SLA breach, authentication failure, timeout, rate limit, partial success, retry exhaustion, and reconciliation after recovery. Record synthetic identifiers, run evidence, and checks not executed.
11. Reconcile sandbox results. For each test, compare the submitted capture data, workflow decision, resulting CRM record, consent and attribution state, assigned owner, SLA values, logs, and external side effects. Explain every difference; do not silently repair evidence before recording it.
12. Prepare disablement and production-review handoff. Export or record the reviewed non-production configuration, previous version, changed objects, disabled steps, known platform differences, required production credential references, monitoring, approval gates, rollback or disablement steps, and reconciliation procedure. Do not activate production.

## Stop conditions

Stop with a precise blocked-handoff report when no authorized sandbox or editable export exists, environment identity is uncertain, a connector could reach production, safe synthetic testing is unavailable, routing or consent rules conflict, credential values would have to be exposed, required permissions are absent, overlapping changes cannot be preserved, or requested actions exceed the supplied authority. Do not return generic configuration instructions as though implementation occurred.

## Output contract

Return:

1. Implementation status: Implemented in sandbox, Partially implemented, or Blocked.
2. Environment and evidence record confirming what was inspected and why it is non-production.
3. End-to-end field and decision map: source field, validation, destination field, consent or attribution treatment, qualification rule, route, SLA behavior, failure state, and owner.
4. Configuration change manifest: artifact or object, prior state, new state, rule served, activation state, and rollback action.
5. Deduplication, idempotency, retry, partial-success, and reconciliation design as implemented.
6. Routing and SLA matrix including territory, owner availability, round-robin, fallback, calendar, and exception behavior.
7. Synthetic test ledger: test ID, input, expected decision and record, observed result, run or log evidence, side effects, and Passed, Failed, Not run, or Blocked status.
8. CRM-to-source reconciliation results for every executed test.
9. Privacy, consent, attribution, security, platform, and environment limitations.
10. Unresolved decisions, accountable owner, and smallest safe next action.
11. Disablement, configuration restoration, duplicate cleanup, and post-rollback reconciliation instructions.
12. RevOps, CRM-owner, privacy-reviewer, and release-owner handoff explicitly confirming that real leads were not used and production automation remains disabled.

Completion requires a confirmed non-production environment, traceability from each approved rule to implemented configuration and an observed test, reconciled synthetic records, no unauthorized external side effects, documented failure paths, preserved unrelated work, and a tested or reviewable disablement path. Use Partial or Blocked when any material condition is unmet. Never claim the automation is production-safe, compliant, activated, or successful without corresponding sandbox evidence and accountable approval.

## Variables to Replace

1. approved_capture_schema
2. sandbox_and_integration_context
3. qualification_routing_and_sla_rules
4. consent_and_data_handling_requirements
5. acceptance_criteria_and_authorized_scope

## How to Use

Open Codex with the authorized sandbox repository, editable CRM workflow export, or explicitly permitted non-production integration tools. Replace all five variables with the approved capture schema, sandbox and integration evidence, routing and SLA rules, consent and data-handling requirements, and exact acceptance criteria and permissions. Supply connector or API documentation, sanitized field definitions, configuration exports, synthetic test cases, and permitted verification commands, but never paste credentials or real lead data. Confirm the environment is non-production before authorizing changes. Review the change checkpoint, synthetic test ledger, reconciliation results, and disablement plan with the RevOps owner, CRM administrator, privacy reviewer, and release owner. Production activation must be a separate authorized action.

## Example Use Case

A RevOps team has approved form fields, consent behavior, lead-source preservation, qualification thresholds, territory rules, round-robin queues, owner-absence fallback, and business-hours SLAs. Codex receives an editable workflow export, a CRM sandbox, synthetic leads, and permission to change only the sandbox workflow. The Prompt directs Codex to implement validation, mapping, deduplication, routing, SLA and retry behavior; keep messages and production endpoints disabled; run boundary and failure tests; reconcile every synthetic submission to its sandbox record; and return a disablement and review handoff without activating production.

## Tags

1. automation
2. crm
3. crm-automation
4. lead-routing
5. revops
6. sales-operations
7. workflow-automation
8. sla
9. idempotency
10. data-privacy

## Dates

Published: 2026-09-09
Updated: 2026-09-09