For suppliers
Invite teammates, assign a role preset or an exact set of capabilities at the right scope, and separate who can see pipeline work from who can act on it.
4 min readUpdated
Something missing from this page? Email help@tap.co
There are no fixed job titles behind a teammate's access. Each person holds one or more capability grants, and each grant is a specific permission, such as Receive RFPs or Confirm Orders, applied at a scope: your whole organization, one market, or one station. What a teammate can do is the union of their grants.
Two people can have very different access on the same station. One can see every incoming RFP, another can also submit Avails against it, and a third can confirm the Order that follows. None of that requires a separate role system beyond the grants themselves.
Open Team and choose Invite teammate.
Enter the teammate's email
Only that address can accept the invitation.
Choose access if you manage permissions
If you also have Manage team permissions, pick one of the presets below or select individual capabilities. Otherwise, send the invitation without additional grants.
Choose the scope
Pick the organization, a market, or the specific stations the access applies to, depending on what the preset needs.
Send the invitation
The invitation expires after 14 days if it is not accepted.
Inviting several teammates at once works the same way through Import CSV. Each record requires an email. Role is optional, and a record without one defaults to Read-only.
The invite and permission editors offer starting presets:
| Preset | What it covers |
|---|---|
| Admin | Full access to everything across every station. |
| National sales manager | Full sales authority and can assign work across all stations. |
| Market manager | Views commercial work in chosen markets and manages responses for their stations. |
| Sales rep | Views assigned RFPs and Deals they create. No Order or inventory authority. |
| Traffic / ops | Inventory, rates, and Memories. No Avail or Order authority. |
| Read-only | Views everything. Changes nothing. |
A preset applies a known set of grants across the scope you choose. If a teammate's actual grants do not exactly match a preset, either because you started from a preset and then adjusted a capability, or built the set by hand, Tap labels their access Custom. That is expected for anyone whose access does not fit the standard shapes.
A capability lives at one of three grains:
Invite teammates, Manage team permissions, and Org settings are organization-only. They describe administering the workspace itself and cannot be narrowed to a single station.
View pipeline is independent from every action capability. It answers whether a person can see a piece of commercial work, while capabilities like Edit Avails and Confirm Orders answer whether they can act on it. Grant View pipeline at whichever scope fits: organization-wide for someone who should see all commercial activity, market-wide for a regional manager, or station-scoped for someone tracking one property closely. A person with View pipeline for a market can follow every incoming RFP and Deal across that market's stations without being able to touch an Avail or an Order.
Selecting a teammate on the Team page opens the same permission editor every time: their current role or Custom label, a full capability matrix broken out by station, and controls to grant or revoke any capability at organization, market, or station scope. Changes stay staged in the editor, showing exactly how many grants will be added and removed, until you save.
Invite teammates authorizes sending invitations. Manage team permissions is also required to attach or change an invitee's permission set. Without it, the invitation must be sent without grants. Only Manage team permissions authorizes changing an existing teammate's access.
From the same editor, Manage team permissions also lets you remove a teammate from the workspace. Removing someone clears their permission grants and their RFP assignments along with their membership, so review any unsaved changes first. The action asks for confirmation once before it runs.