#Attendant assignment

The attendant is the account member responsible for a contact, an opportunity or a conversation in the CRM. Assignment can be fixed (you pick the person) or automatic by team, which shares leads between attendants in a round-robin.

Before you start

• Role: to create teams, add members and configure distribution you must be Owner, Admin, or an Attendant with the coordinator subrole. An Editor or a plain Attendant can only view the teams screen (an Attendant sees only the teams they belong to).
• Plan:
• A plain Attendant only sees the contacts, opportunities and conversations assigned to them. Owner, Admin and coordinator see everything.

#Who sees what

The CRM decides what each person sees from their workspace role:

• Owner and Admin see everything — every opportunity, booking and conversation in the workspace.
• A coordinator (an attendant subrole) also sees everything.
• Every other role, including Editor and a plain Attendant, is scoped to their own records.

That scoping is what makes assignment matter: until someone is the attendant on a card, it stays invisible to people with their own scope.

#Fixed assignment

With fixed assignment you choose the responsible attendant by hand — when creating the opportunity, or from the card itself. It is the direct route when you already know who should handle that lead.

#Who can change the owner

The name of whoever owns the opportunity always shows at the top of it, including for people who cannot change it. In that case the field is read-only: you can see who the owner is, but the list will not open. Hover over it to see why.

To hand an unowned opportunity to a colleague, take it first, then hand it over.

#Booking sets the owner

Under Pipeline settings → Ownership there is a Booking sets the owner switch. With it on, booking a meeting for an opportunity hands that opportunity to whoever runs the meeting — the path for teams where one person prospects and books, and another takes over from there.

The switch starts off: turning it on changes card ownership automatically, and on a team with restricted scope that also changes what each person sees in their list.

Two details:

• It applies to every booking source — public page, automation, or booked by hand. It also applies when you link an opportunity to a meeting that already existed.
• If the person running the meeting is not an attendant of that opportunity's pipeline, you are asked before booking (see below).

#When the calendar belongs to someone outside the pipeline

Picking the calendar of someone who is not in that pipeline opens a confirmation with three ways out:

• Add and schedule — the person joins the pipeline and takes the opportunity. They will start seeing that pipeline's opportunities.
• Schedule without adding — the meeting is booked and ownership stays with whoever had it.
• Cancel — nothing is booked; you go back to the form.

To add someone to a pipeline you must be part of it yourself (or be an Owner, Admin, or coordinator). If you cannot, the meeting is still created and a notice explains that ownership did not change.

#Which calendars an attendant sees when booking

By default, when booking a meeting any attendant can pick any calendar in the workspace. That is what lets an SDR book straight into the closer's calendar.

If your team splits pipelines by role and you prefer the opposite, turn on Restrict which calendars the attendant sees under Pipeline settings → Ownership. With the lock on, booking for an opportunity in that pipeline shows only the attendant's own calendars and those of teams they belong to.

Three things to know:

• The lock is per pipeline, and it is read from the pipeline of the opportunity you picked.
• Booking without an opportunity (from the Tasks menu) shows every calendar — there is no pipeline to read the rule from.
• Owners, Admins and coordinators are not affected: their scope is unrestricted by definition.

#Pipeline attendants and person types

Each pipeline has its own attendant list, configured in the Attendants tab of the pipeline settings. That screen has two independent parts:

• Person types — the roles that exist on this pipeline's opportunities (for example SDR or Account Executive). They define the assignment fields on the card and the commission per role.
• Available attendants — who takes part in this pipeline.

Any attendant can be added to any pipeline. You do not have to pick a person type first, and the attendant does not need to already hold that type — whoever administers the pipeline decides freely who joins. The types an attendant already has are shown next to their name for information only.

Likewise, when filling a role inside an opportunity, the list offers every attendant linked to the pipeline (plus Owner and Admin, who can always be assigned), whatever person types each one holds.

#Distribution by team

A team is a group of attendants that receives leads automatically. Under Teams → the team → Availability you pick the distribution mode, and that is what decides how the next lead is handed out.

The mode applies to every door that distributes through that team: cards created by the pipeline, the Assignment action in stage automations, list or segment imports, the "Owner" bulk action, and the tie-break on team calendars.

#Round-robin (balances the load)

The default mode, and the only one that existed before. When you add a member you set how they enter the rotation:

• Weight — attendants with a higher weight receive proportionally more leads.
• Priority — the tie-breaker when weights are equal; higher priority wins.
• Fixed member — always takes part in assignment and does not enter the rotation.

Among those eligible, ties break by weight, then priority, then whoever went longest without a lead, and finally at random. Temperatures form separate queues: each temperature alternates on its own, so the per-person total may not alternate.

#One by one (a queue in the order you set)

Pick One by one when the rule on the floor is "one lead each, in order". Turning the mode on reveals the Rotation queue: drag members to set the order, and the next lead goes to the next person in line.

What changes compared to Round-robin:

• A single queue. Temperatures stop forming separate queues, and that is what makes the alternation hold for the per-person total. Leads of different temperatures in the same round do not break the order.
• The order starts as the team join order and becomes whatever you set. A new member joins at the end of the queue.
• Weight, priority and fixed member are not used. They stay visible on the member's settings, struck through and flagged — the mode ignores them.
• Anyone unavailable is skipped without losing their turn. When they return they rejoin at the current position; they do not receive a burst of leads to make up for the time they were out.
• The queue shows whose turn just passed. The member who received last is marked, and so is the next eligible one — that is how you check why a lead went to a given person.

Reordering the queue applies to the very next distribution and does not restart the rotation: whoever received last remains the starting point, even after changing position.

Switching modes is your call and never happens on its own: teams that already existed stay on Round-robin until you change them.

#Temperature and cap

Each team member can have rules per lead temperature (warmer leads, for example). Temperature applies in both modes: whoever does not handle the lead's temperature does not get that lead (in One by one, they are skipped without losing their turn).

The limit changes unit with the mode:

Anyone at their limit drops out of the rotation until space frees up — and if every eligible member is capped, distribution declines and the lead gets no automatic attendant.

The limit is checked at each distribution. If several leads arrive at the same instant (an import firing alongside a form, say), one or two may go over the cap: each distribution sees the load from before the others. In normal use, one lead after another, the cap holds.

In One by one the limit can also be turned off for the whole team, with the Respect assignment limits switch (on by default). Off, a member at their limit does receive when their turn comes.

#Why the card has no owner

When automatic distribution cannot pick anyone, the opportunity is created without an owner — and the card states the reason where the attendant's name would be. Hover over it to read the full sentence.

Two details that avoid confusion:

• The reason is a snapshot of when the card was created. Fixing the setting now leaves older cards showing the old reason — they do not re-enter the rotation on their own. Assign an owner manually and the notice goes away.
• Moving the card to another pipeline clears the reason: it described the original pipeline and would not hold at the destination.

#Where each thing is decided

Two screens, two different decisions — mixing them up is the most common cause of "I changed it and nothing happened":

A pipeline with no team has no rotation: the opportunity goes to the pipeline attendant with the fewest open opportunities. To distribute in a queue, pick a team.

#Drawing at random on a single stage

Beyond the pipeline-wide distribution, each stage can have its own Assignment automation — including a random draw among hand-picked agents, with no team to build. See Draw the owner at random from agents you pick.

#Related

• Draw the owner at random from agents you pick
• Build your first pipeline
• Contacts
• Messaging — where the conversations arrive.

#If it didn't work

• You cannot create teams or change distribution: your role lacks permission — see no permission.
• An error adding an attendant already on the team, or a duplicate team name: see the error codes (Portuguese).
• A lead got no automatic attendant: read the reason on the card itself, under Why the card has no owner — it points at which setting needs to change.
• You picked One by one and someone received twice in a row: open the team's Rotation queue. The mark on whoever received last shows the starting point, and anyone out is flagged — usually it is a member skipped between the two, not the queue out of order.
• You changed weight or priority and nothing moved: check the team's mode. On One by one neither field is used; the order is the queue.