What’s Fixed
An automation step that assigns a contact to a group could report Completed without assigning anybody. The contact stayed exactly where it was — still in its pond, or still with its previous owner — while the run’s Execution Details panel showed a green step and a line reading “Assigned to <name> from group <group>”. The name it showed was the owner the contact already had, so at a glance the step looked like it had worked. Nothing appeared in the contact’s Change Log, the group’s round-robin never advanced to the next member, and nobody was notified.
The step now does what it says, and says what it did:
Bug Fixes
- Assigning to a group works. A contact assigned to a group is actually handed to the group’s next round-robin member, or parked on the group with a claim opened for first-to-claim groups. This works whether the contact was sitting in a pond or assigned to an individual agent beforehand.
- A step that cannot assign now reports Failed, with the reason on the step — for example that a round-robin group has no available members, or that no claim could be opened. It is no longer possible for the panel to show Completed and name an assignment that did not happen.
- A failed Assign step no longer leaves the contact stranded. If the assignment cannot be completed the contact is left exactly as it was found — same owner, same pond, still visible in that pond’s queue, and the group’s round-robin position untouched.
- Assigning to a pond puts the contact in the pond’s queue, records the move in the contact’s assignment history naming the pond, and notifies the pond — including when the contact had been in that pond before and the old entry was already claimed.
- An assignment made by an automation is recorded as the automation’s, for every target the step can pick — an agent, a pond, a round-robin group and a first-to-claim group. The assignment record used to credit the contact’s own owner, a person who had not done anything, or nobody at all.
The Execution Details panel now names the real target
The Assign step supports three kinds of target, but the automation canvas and the run timeline always said “Assign to user” and “Assigned user” regardless of which one was configured. That mislabelling fed straight into diagnosing a group step as though it had assigned a user.
- The canvas step summary and the run timeline now say Assign to group, Assign to pond or Assign to user, naming the group, pond or agent where it is known.
- A failed step no longer renders success wording. It used to read “Assigned contact to group” directly beneath a red Failed badge; it now reads “Failed to assign group”, with the reason in the error box below it.
What happens to the rest of the automation
A failed Assign step stops the run at that step, which is how every other failing automation step already behaves — the run is marked Failed and the following steps do not run. Before this fix a discarded assignment reported success, so the run carried on; now that the step tells the truth, the run stops on it. Open the run in Execution Details to see which step failed and why, fix the cause — add a member to the group, for example — and use Retry.
Whether a failed step should stop the rest of the run is being looked at separately.
What has not changed
- Steps other than Assign are unaffected — their success, failure and skip behaviour is exactly as before.
- Contacts already assigned by an automation are not retroactively changed. The fix applies to runs from here on.