How a Form Decides Who Gets the Lead
One decision, made once, that governs everything downstream
What It Is
Every form submission ends up owned by one member of your team. That person becomes the contact's owner, the organiser of any meeting booked, the one notified that the lead arrived, and the context for every follow-up email, message and call the form sends.
Zyntro makes that decision once, before anything is written, and then carries it through the whole submission. Nothing downstream recalculates it.
How It Works
The resolution order
Zyntro works through four possibilities and stops at the first that applies.
1. A group calendar is attached. The member was already chosen when the booking was resolved — picked from those genuinely free for the slot, using the schedule's strategy. That choice stands. The lead is never rotated a second time over the same group of people.
2. Any other calendar is attached. The lead goes to the calendar's owner. The booked slot physically sits on their calendar, so the meeting, the busy time and the lead all belong to the same person.
3. No calendar is attached. Now the form's own routing settings apply. One member in the pool means they take everything; several means they rotate.
4. Nothing resolvable. The lead falls back to the member who owns the form, so a submission is never left unassigned.
Who is eligible
Only Active members can receive a lead. Members who are Inactive, Suspended, or Pending — invited but never signed in — are removed from consideration. If filtering empties the pool entirely, the form's own member takes the lead rather than it being orphaned.
Returning contacts keep their owner
If the person submitting is already a contact, they stay with whoever owns them. A second submission does not move them to this form's member, and it does not disturb team members who were added to that contact by hand.
This matters on forms people complete more than once — surveys, feedback, repeat bookings. Ownership is sticky by design.
Why It Matters
The two rotations are not the same thing, and this is where most confusion starts.
A group calendar rotation decides who hosts a meeting. It is configured on the calendar and its schedule, it only considers people actually free for the chosen slot, and it applies whenever that calendar is used — by a form, a booking page, or anything else.
A form routing rotation decides who owns a lead. It is configured on the form, in Lead Routing, and it applies only when no calendar is attached to the form.
They never both run. If a calendar is attached, the calendar decides and the form's routing list is ignored. If no calendar is attached, there is no booking to host and the form's routing decides.
The practical consequence: setting up a rotation in Members in the rotation on a form that takes bookings has no effect. People do this, see leads going somewhere else, and conclude routing is broken. It is working exactly as designed — the calendar simply outranks it.
Examples
A demo form with a group calendar shared by three salespeople
Someone picks Thursday at 2pm. Zyntro checks all three for that slot, finds two free, and the schedule's strategy picks between them. That person hosts the meeting and owns the lead.
Anything set in the form's Members in the rotation is irrelevant here.
An enquiry form with no calendar, routing across four people
No booking, so the form's routing applies. Zyntro counts how many contacts from this form each of the four already owns and gives the lead to whoever has fewest. Ties go to pool order.
The result is even distribution over time without a counter to drift out of sync.
A consultation form attached to one person's own calendar
The slot sits on that person's calendar, so the lead is theirs. No rotation happens at all, whatever the form's routing says.
An existing client submits a feedback form
They are already a contact with an owner, so they stay with that owner. The notification goes to the person who actually manages the relationship, not to whoever happens to own the feedback form.
Info: The form routing rotation counts contacts by the form's name, which is also what gets stored as each contact's source. Renaming a form therefore restarts the counts from zero. That is harmless — distribution stays even from that point on — but it explains a rotation that appears to reset.
