Imagine that two new demo enquiries are waiting in your People records. Three representatives share inbound coverage. You want each eligible contact to receive an owner, preserve contacts that already belong to someone, and avoid touching the rest of the database. This is an ideal first project for a CRM workflow builder because the outcome is concrete: inspect the two contacts before the run, execute a tightly bounded workflow, and inspect them again afterward.
Start with a written assignment rule. For this example, an eligible contact belongs to the intended test cohort, is ready for sales follow-up, and has no established owner. A contact outside that cohort should never reach the mutation step. A record with an existing owner should remain unchanged unless you have deliberately designed a reassignment process. These distinctions prevent a broad automation from quietly overriding relationships your team already maintains.
In Intelligent CRM, the useful sequence is Manual run, Find records, Loop, an optional per-record Filter, Round robin, and Update record. Round robin returns a selected workspace user; it does not itself change a contact. Keeping the selection and update steps distinct makes the workflow easier to inspect. The same design can later support related follow-up work, but establish correct ownership before adding more actions.
1. Define the smallest useful cohort
Use two or three deliberately chosen test contacts whose current owner and qualification fields you can inspect. Prefer a dedicated test marker or exact filter over a common first name, broad source category, or an arbitrary first page of results. Write down the identifiers of the records you expect to change. If the query returns another record, treat that as a configuration failure even when the assignment logic would otherwise be correct.
Place the strongest supported eligibility conditions in Find records. A search limit applies to the records returned by that search; a later Filter does not search the rest of the database to replace rejected items. For example, finding four contacts and then keeping only a named cohort can produce zero eligible contacts even when the cohort exists elsewhere. Inspect the returned records and their count before interpreting a successful run as evidence that the intended contacts were processed.
2. Put the assignment inside the loop
Find records returns a collection. Update record changes one record. Connect the collection to Loop and place the per-contact actions on its per-item branch. The current loop item then identifies the contact being handled in that iteration. If Round robin sits before the loop, the workflow can select one user once and reuse that selection for every contact. When the desired behavior is rotation across contacts, selection belongs inside the loop.
Use the loop completion path for work that should happen after the collection has been processed, such as a deliberate summary step. Keep ownership changes on the per-item path. This matters even for a two-record demonstration: a graph that accidentally works for one item can hide an incorrect branch placement. Check the graph structure and the per-iteration run data rather than relying on the left-to-right appearance of the canvas alone.
3. Separate qualification from choosing a representative
An optional Filter inside the loop is useful when eligibility depends on values in the current item or on context produced earlier in that iteration. In the manual workflow editor, Filter is a control gate: it continues only when its configured conditions match. It does not produce a replacement contact record. After a matching Filter, continue to reference the current loop item when selecting the record to update.
Put the eligibility check before Round robin so rejected contacts do not consume a selection in the rota. Then choose the intended workspace members or supported role groups for the rota. Intelligent CRM verifies those selections and uses an atomic, retry-stable selection operation. That protects selection consistency, but it does not prove that all selected people have equal capacity or identical territory responsibilities. Define the eligible team deliberately; rotation is an ordering policy, not a complete staffing policy.
4. Map the contact and owner to their different fields
In Update record, choose People as the object and select Loop → Current loop item for Record. The action accepts a supported record identity or its ID, and a supplied record must belong to the selected object. Under attributes to set, choose Owner ID and bind it to Round robin → userId. The Record field identifies the contact being changed. Owner ID identifies the teammate who should own that contact. Exchanging those inputs cannot express the intended operation.
Use the relationship field for assignment rather than writing a person’s name into a free-text owner label. A label can help a reader recognize someone, but it is not a reliable user identity. Also resist mapping the entire current contact into the attributes to set. Update only the fields required by the rule. The record input establishes identity; the values section defines the actual changes, which keeps unrelated contact information out of the mutation.
5. Verify outcomes beyond the green run status
Before running, record each test contact’s ID and owner. After running, inspect the search result, loop iterations, selected user IDs, and update results. Finally reopen the actual contact records and compare their owner relationships with the expected selections. A run can finish without assigning anyone if every item was filtered out. Conversely, a failed run may have completed an earlier iteration before a later item failed. The overall status is a starting point for investigation, not the complete business outcome.
Use at least four checks: one eligible unassigned contact, one contact with an established owner, one contact outside the cohort, and an empty search. The first should be assigned. The second and third should remain unchanged according to the written rule. The empty search should produce no ownership changes. Repeat the deliberate test run and verify your eligibility conditions prevent already assigned contacts from being redistributed when that is the intended policy.
6. Add follow-up tasks only after ownership is correct
A contact owner and a task assignee are related concepts, but they are separate relationships. If the next step creates a task, link it to the contact and provide the selected assignee using the shape required by that task action. The manual Create task action uses an assignee collection, so a single round robin user must be supplied as a one-item collection where required. Do not assume a scalar owner field and a task’s assignee list are interchangeable.
Write a task description that tells the representative why the contact qualified, what to do, and what counts as completion. Then decide how repeated runs will avoid duplicate follow-up tasks. Rechecking that the contact is unassigned can prevent another assignment run, but it is not a universal task deduplication strategy, particularly if assignment succeeded and task creation failed. Test that partial-completion case before linking additional outbound actions or expanding the cohort.
7. Publish the version you have actually reviewed
Save and validate the graph, then publish the version intended for execution. The manual workflow editor separates the editable draft from published versions. An edited draft is therefore not proof that a later execution used those edits. When investigating a result, compare the run’s version with the version you reviewed. Keep the initial manual trigger while learning the behavior; changing both the trigger and the assignment policy at once makes failures harder to attribute.
Expand the cohort gradually after the small test passes. Define who maintains the rota, who handles a failed update, and when existing owners may be replaced. Review unusual concentrations of assignments rather than assuming equal counts imply good service. A CRM with workflow builder capabilities becomes useful when the operating rule remains understandable after the original author has moved on. Leave a short description beside the workflow explaining eligibility, ownership protection, and the expected record changes.
Verify a rotation without depending on a particular starting person
A sales operations manager creates two unassigned test contacts and marks them for an assignment trial. Find records selects that exact marker. Loop iterates the returned contacts, Filter checks that each remains eligible in the selected data, and Round robin chooses from three reviewed teammates. Update record receives the current loop item and sets Owner ID from the selected userId. The manager records the rota selections from each iteration instead of assuming that the first alphabetically listed representative must receive the first contact.
The acceptance check is that each intended contact now has the user selected for its own iteration, unrelated contacts remain unchanged, and another deliberately initiated run does not redistribute the assigned cohort under the configured eligibility rule. This is an illustrative verification procedure, not a claim about a customer deployment. If one update fails, the manager inspects which previous updates completed before deciding what to rerun.Before expanding your first assignment workflow
- Identify the exact contacts expected to change and capture their starting owners.
- Apply supported selection criteria before a search limit can exclude the intended cohort.
- Place per-contact qualification, rotation, and update inside the loop.
- Use the current contact for Record and the selected workspace user for Owner ID.
- Verify the live records as well as the run status and published version.
- Exercise an existing owner, an excluded contact, no results, and a repeated run.
- Test task assignment shape and duplicate behavior before adding follow-up work.
Make the first workflow small enough to explain
Reliable lead assignment starts with a narrow population and two clear identities: the contact receiving a change and the user receiving ownership. A loop provides one execution context per contact, eligibility determines whether it should continue, and the update writes only the intended relationship. Those responsibilities remain distinct even when the canvas makes them look like one simple line.
Once you can predict and verify a small batch, extend the same method to a broader cohort, a different rota, or carefully designed follow-up tasks. The value of CRM workflow automation comes from consistently producing the intended record state, including when nothing should change.