Your working checklist
- Identify the real source and module.
- Confirm the rule used by that source.
- Compare incoming values with criteria.
- Check ordering and the intended owner.
- Inspect later updates to ownership.
- Test returning inquiries.
- Verify the record, owner and next action together.
1. Identify the exact record-creation route
Write down the module, source and action: a webform submission, an import, a connected tool or an API request. Then identify the record you expect that action to create. A test made through a different route can give you a reassuring result while the real source still fails. Keep a simple trace: source event, CRM record, assigned owner and the next task. Use fictional information in a controlled test and avoid changing the production rule until you understand the failing path.
2. Check which rule the source is using
Open the source configuration and confirm the selected assignment rule. For an integration, inspect its documented rule-setting options. Zoho’s V8 Insert Records API documents lar_id as the assignment-rule identifier, supplied alongside data. That setting is distinct from a general workflow trigger. An API-created record is not proof that the requested assignment was applied. The right implementation depends on your module, edition and integration; use the current official documentation for that route.
3. Compare actual field values with the criteria
Check the values that reached CRM, rather than the wording shown in the customer-facing form. A source might send a location label where the rule expects a territory code, omit a service, or populate a different field. Map the source field to the CRM field and agree on acceptable values. Make one controlled test per relevant branch. Include a missing or unexpected value so you can see the fallback instead of assuming it works.
4. Inspect rule ordering and the intended owner
Read the applicable entries in their evaluated order and test any overlapping conditions. Confirm that the intended owner, team or queue is available under the configuration you actually use. A broad condition and a narrow one can describe the same record; the business needs an explicit answer about which should win. Record the expected owner for each test case before running it. That gives the reviewer a clear pass or fail instead of a subjective impression.
5. Look for a later ownership change
Inspect the record history and the integrations that can update it. A record can initially reach the right owner and then be changed by another process. Compare timestamps around creation, assignment and subsequent updates. Separate three questions: was the record created, was ownership correct, and did the person receive the intended next action? Correcting one does not establish the others. Keep any logs shared outside your account free of personal data and access credentials.
6. Decide what a returning inquiry should do
A repeat inquiry might update an existing record instead of creating a new one. Decide whether the previous owner should stay responsible, a review should be requested, or a new assignment should be made. Test the connector’s actual create/update behavior. Repeated source events also need a policy for notifications and follow-ups so one person is not contacted several times by accident. This is a business rule to define, not a reason to create a duplicate record automatically.
7. Verify the complete handoff
Run complete, incomplete, unmatched and repeated fictional inquiries through the real entry route. Inspect the destination record, owner and expected task or notification. Keep a named fallback for cases that cannot be assigned normally. The handover should explain the route, rule, field mapping, checks and who reviews failures. If the problem spans several tools, scope that whole route before commissioning another isolated rule.