Teams work the same way whether you run one hotel or 75. What changes at scale is that a flat list stops being usable, and that group-wide routing and local routing start to disagree. Team scope is how you settle that: each team belongs either to your whole organisation or to a single property, and Bookboost knows which one should win.
If you are setting up teams for the first time, start with Teams in Unified Inbox, which covers creating a team, the rule types, and rule groups. This article covers only what is different once you have more than one property.
The two scopes
Every team belongs to one of two scopes, chosen when you create it.
Scope | The team can receive | Who can see it |
Organisation | Conversations from any property in the organisation | Operators with team access, subject to their own property access |
Property | Only conversations from the property it is scoped to | Operators who have team access and belong to that property |
A property scoped team cannot reach across properties. It will never pick up a conversation from a different property, whatever its rules say. This is the point of it: a rule written for one hotel cannot quietly start routing another hotel's guests.
Teams are also only visible inside their own scope. An organisation scoped team does not appear when you are viewing a single property, and a property scoped team does not appear in the organisation view. If a team you were expecting has vanished, check which scope you are looking at before assuming someone deleted it.
Which team gets the conversation
With one property, the team list is read from the top down and the first match wins. With more than one property there is a step before that.
Scope is checked first. If a conversation matches both a property scoped team and an organisation scoped team, the property scoped team takes it.
Then position in the list. Among teams that are still in play, the list is read from the top down and the first match wins.
Then your fallback. Keep a team at the bottom with a catch-all rule so nothing arrives unassigned.
In practice this means you do not have to choose between group-wide consistency and local control. Write the rules that should apply everywhere once, at organisation scope. Then add a property scoped team only at the locations that genuinely do something different, and it will override the group rule for that location without you touching the group rule at all.
Teams belong to the property environment they were created in
A team is tied explicitly to the property environment you created it in, and its rules apply there and nowhere else. A team built for one environment will not start routing conversations in another, even if the rules would otherwise match.
The same boundary applies to what you are shown. The teams and filter options offered to you are the ones you have access to, not everything that exists across the organisation.
Finding the rules that apply to one property
Past roughly 10 teams, scrolling the list stops working. Use the filters.
Filter by property to see the full rule set that applies to one location, which is the fastest way to answer "why did this hotel's message go there".
Filter by operator to see which teams a person is actually in, which is the fastest way to answer "why is this person not receiving anything".
Filter by status to separate active teams from inactive ones.
Filter by access to narrow the list by who can reach the team.
Who can see which teams
Visibility follows the property access each operator already has, set per operator in Settings > Operators > Accessible Apps.
An operator only sees teams for the properties they have been assigned to.
For a property scoped team specifically, an operator needs team access and needs to belong to that property. Team access on its own is not enough.
If someone is seeing too much or too little, the fix is almost always their property assignments rather than the team itself. See Property-level data visibility in the Unified Inbox and Adding and managing operators.
What happened to the teams you already had
Every team created before 19 February 2026 is organisation scoped. Nothing about how they behave has changed, and you do not need to do anything. If you now want one of them limited to a single property, set its scope yourself.
Common questions
We have one group-wide rule but one hotel needs to handle it differently. Do we have to duplicate the rule everywhere?
No. Leave the group rule at organisation scope and add a property scoped team at that one hotel. It takes precedence there, and every other property carries on using the group rule.
Can a property scoped team pick up a conversation from another property?
No, never, regardless of its rules.
A team has disappeared from my list.
Check the scope you are viewing, then check your own property access. Teams are only visible inside their own scope, and only for properties you have been assigned to.
Why can one of my operators not see a property scoped team?
They need both team access and membership of that property. Check their assigned properties in Settings > Operators > Accessible Apps.
Could a team we built for one property start routing conversations at another?
No. A team is tied to the property environment it was created in.
Getting help
Open Help at the bottom of the left menu and choose Talk to Us, or email support@bookboost.io.