Write the rules.
Include the exceptions.

Begin with a workflow you can draw.

Choose one event and one useful next action. Walk through several recent examples with the people doing the work. Write down the normal path, the exceptions, and the manual decisions that are easy to overlook. Check whether the CRM already has a suitable native feature before adding another service.

Map the current state before changing it. Record the relevant fields, the available permissions, the owner of each system, and how the event can be detected. Verify the account's actual access and limits. Do not assume that two products can exchange every field simply because an integration is advertised.

For lead routing, define ownership and fallback.

Start with the event: a submitted form, a qualified record, or a new inquiry from an approved source. Decide what makes it eligible for routing. A record created during a historical import may need different treatment from a new customer inquiry.

Use an explicit rule for the owner, such as territory, existing account ownership, or a supported team queue. Decide which rule wins when more than one applies. Include a fallback for incomplete location data, inactive team members, and records that cannot be matched confidently.

Create a next action the receiving person can understand. Include the reason for assignment and the context needed to respond. Keep an unassigned queue visible to a named operator, with a way to find how long records have been waiting.

• Run the same input twice: it should not create duplicate tasks.
• Test an inquiry from an existing customer before making a new account.
• Test a missing field and an unavailable owner.
• Confirm that an imported record does not accidentally start new outreach.

For synchronization, assign authority field by field.

“Keep both systems in sync” is too broad to implement safely. List the fields that need to move and identify the authoritative source for each. The CRM might own the account manager while the billing system owns an invoice's payment status. Avoid letting two systems continuously overwrite the same field without a conflict rule.

Choose a stable way to match records. A person's name alone is rarely enough. An email address can change and may not uniquely identify an organization. Preserve stable external record identifiers where the systems allow it, and send ambiguous matches to review.

Specify how blank values, intentional deletions, and older updates behave. Decide whether the first run should import historical records or only process new changes. Keep that initial import separate from everyday processing so its effects can be inspected.

Prevent a change from returning as a new change in the opposite direction. Make retries safe: repeating a partially completed run should not duplicate a customer, a note, or a task. Keep enough run information to understand which source event caused a change.

For follow-up, define when it should stop.

Choose a real business event and an appropriate next action. For a first release, a task for a team member is often easier to evaluate than automatically sending a message. Name the person responsible, the relevant context, and the rule used to choose the due date.

Define the stop conditions before scheduling the action. A reply, completed purchase, closed opportunity, changed owner, or manual pause may make the original follow-up unnecessary. Re-check the current record when a delayed action becomes due instead of relying only on the state when it was first scheduled.

If the workflow sends messages, agree on the audience, approved content, consent requirements, and suppression rules for that channel. Check the current provider behavior and applicable requirements with the responsible operator. Do not equate an address in a CRM with permission for every kind of communication.

• Show the operator why a task was created.
• Keep a straightforward way to pause future actions.
• Test a reply that arrives just before a task is due.
• Make the time zone and business-day assumptions explicit.

Launch with a small, observable scope.

Use test records or a limited set of approved records first. Compare the resulting changes against the written rules. Include duplicate events, missing fields, a rejected request, and an interrupted run in the review. Have a named person check the exception queue.

Before broadening the workflow, agree how to pause it and how to identify the records it changed. A run log should be useful without collecting unnecessary sensitive information. Confirm who sees failures and how that person can recover the work after fixing the cause.

Measure the workflow's actual result: unassigned inquiries, duplicate tasks, exception volume, or the time between an event and its next action. These observations tell you whether the handoff improved and which part still needs attention.