Your first useful check
Start here.
Create one approved test lead through the actual failing integration. Capture the entry method, fields at creation, selected assignment rule and first owner. Then check whether another process changes that owner.
Is this the right guide?
Use this for initial lead ownership and later reassignment. Zoho documents assignment rules for leads created through imports, webforms and API; manual creation is not an equivalent reproduction of those paths.
What you can check and who can help.
- You can start here
- You can identify the lead's source, compare its routing fields and note who owned it first and later. Use a test record created through the real connection.
- Bring in the responsible specialist
- Ask the Zoho or integration owner to inspect assignment-rule settings, API requests and later owner updates. API requests are messages sent between software tools.
Tools and access you need
Zoho assignment rules, lead field and ownership history, form or integration configuration, and a test user with the required permissions. Confirm feature availability in your edition.
Before changing settings, keep a copy of the current configuration so you can restore it. Use approved test records and remove customer details from shared evidence.
Follow the steps.
Start at step 1. Each result tells you what to check next; you do not need to change every setting mentioned.
Use the real lead source
You reproduce; the integration owner verifies invocation.
- Look here
- Find whether the failed lead came through an import, webform or API connection. Zoho documents these as assignment-rule entry paths.
- Check this
- Create an approved test using that same path. Ask which assignment rule the import, form or API request selects or invokes.
- What it means
- A manually created lead is not an equivalent test. A correct rule cannot help if the connection never invokes it.
- Next move
- Confirm the rule runs before changing its conditions. Give the integration owner the test record and creation time.
Check the information available at creation
CRM and integration owners agree timing.
- Look here
- Inspect the test lead's country, product, territory and source fields at the time it was created. A field is one item of information in the record.
- Check this
- Were the routing values present then? Were country names and codes consistent? Did another tool add the value later?
- What it means
- A rule cannot use information that has not arrived yet. A blank country or inconsistent value may send a lead to the wrong route.
- Next move
- Agree whether the needed value should arrive before creation or whether a supported later process should assign the owner. Send incomplete records to a monitored backup owner.
Test the rule with a small routing table
Administrator checks configuration; sales confirms expected owners.
- Look here
- Open the assignment-rule configuration with the Zoho administrator. Make a list of each supported territory or product and its expected owner.
- Check this
- Test a normal match, an overlap, an unrecognized value and missing information. Check that the intended owners are still eligible in the current configuration.
- What it means
- Overlapping conditions and missing values need deliberate behaviour. The fallback is the owner or review queue used when no normal route fits.
- Next move
- Compare results with the rule order and options documented for your edition. Do not reorder rules without knowing which test failed.
See whether ownership changes later
Specialist check: CRM or integration owner.
- Look here
- Inspect ownership history and updates after the lead was created. Check workflows, custom functions and integration updates that can change the owner.
- Check this
- Note the first owner, final owner and change times. Which process made any later change?
- What it means
- Correct initial assignment followed by an overwrite is a later-update problem, not necessarily an assignment-rule problem.
- Next move
- Agree which process is allowed to control ownership. Preserve existing account ownership where that is the intended sales policy.
Make exceptions someone’s responsibility
Sales owner confirms the follow-up process.
- Look here
- Inspect the fallback owner or queue and the expected notification or follow-up task.
- Check this
- Who reviews incomplete leads? How do they see why routing failed? Does the final owner receive the agreed notification?
- What it means
- An assigned lead can still be neglected. Routing succeeds commercially only when someone can act on the record.
- Next move
- Name a fallback reviewer and review schedule. Test the final owner after all automation has run. Review old-lead reassignment as a separate project.
Keep the useful evidence.
Use this table as a reference while following the steps. Keep the information that identifies where the journey failed; remove names and email addresses before sharing it.
| Where to look | Capture | What it tells you |
|---|---|---|
| Creation path | Webform settings, import configuration or API request details | Confirm the intended rule is invoked for this entry method. |
| Routing inputs | Country, territory, product and source at creation | Later information added by another tool cannot explain what a creation-time rule actually saw. |
| Owner timeline | Initial owner, later owner and update timestamps | A correct first assignment followed by an overwrite is a downstream conflict. |
| Exception handling | Fallback owner, reason and monitoring responsibility | An assigned but unmonitored fallback is still a sales handoff failure. |
Platform behaviour and current access requirements: Zoho: Setting up assignment rules ↗ · Zoho: Assignment-rule FAQs ↗
See how the problem happens
Correct rule. Wrong moment.
Suppose territory is blank when a software connection creates the lead. Another tool adds territory later. A rule that needs territory cannot use a value that has not arrived. You can collect the required value before creating the lead, or use a supported later process to assign ownership after it arrives. In the meantime, send incomplete records to a monitored backup owner. Reordering territory rules will not solve a missing input. This example explains a timing problem; it is not a report of client results.
What did you find?
Use the observed behaviour to choose your next check.
All leads from one integration ignore the rule
Check whether that creation path invokes the intended rule.
Only certain markets or products route incorrectly
Inspect actual field values, matching criteria and overlap.
The owner is initially correct, then changes
Inspect downstream updates and competing ownership automation.
The tempting fix to avoid
Do not mass reassign historic leads while debugging. Protect active opportunities, account ownership and ongoing sales conversations.
Test success and the cases that should fail.
One successful test is not enough. Run the applicable cases below with approved test records. Write what happened beside the expected result, so a difference is visible before you release the change.
| Try this | This should happen |
|---|---|
| Each configured territory | The appropriate eligible owner receives the lead through the live entry path. |
| Missing country or product | The documented fallback receives the record and its exception reason is visible. |
| Overlapping criteria | The result matches the documented rule order and intended business priority. |
| Integration updates existing lead | Ownership follows the agreed preservation or reassignment policy. |
| Later automation runs | The final owner remains correct and required notification or follow-up occurs. |
Prove the fix
Tick a check only after you have tested it. Your ticks last while this page stays open; they are your own record of checks, not an automatic account test.
0 of 5 checks completed
When you can stop investigating.
Stop changing assignment rules when the first owner is correct but another process later overwrites it. Fix that later update instead. Release only after normal cases and missing-information cases reach the intended monitored owners.
Keep the problem from returning.
Maintain a table of routing rules outside the automation configuration: entry path, required inputs, matching conditions, intended owner, fallback and reassignment policy. Test those rules after integration changes or sales-territory changes. Agree whether existing account ownership takes priority over geographic rotation. Monitor exceptions and time to first follow-up; an automation completing successfully does not establish that a salesperson acted on the lead.
Questions that change the diagnosis.
Why does a manually created test lead behave differently?
Zoho's documented assignment-rule entry paths are import, webform and API. Reproduce the actual supported source and its configuration rather than inferring its behaviour from manual creation.
Should we reroute every historic lead after fixing the rule?
Treat that as a separate migration. Review active conversations, account ownership and opportunities before selecting the records that genuinely require reassignment.
When you need help
Give the Zoho or integration owner the test lead reference, creation method, routing values at creation, chosen rule and owner-change times. Remove personal details before sharing evidence. Ask which process made the incorrect assignment or later update.
Documentation to keep beside you
Official references checked on 12 October 2026. Menus, permissions and feature availability can change; confirm the details for your account.
Need another pair of eyes?
Show me the step that fails and what you have checked so far. We can trace where the record, event or workflow first goes off course.
Explore the relevant capability ↗ · Read the broader strategy ↗