Team and permissions

For a supplier this is the Team tab of Settings (/settings?tab=team; "Team" in the left menu, shown to roles holding users.view). It loads GET /v1/supplier/admin/users. The old /admin and /admin/users redirect to it. Customer businesses see the same list at /contractor/team. Inviting and changing a role open in a dialog or side sheet, so the page itself only reads.

Who can use it#

• Opening the tab needs users.view, inviting needs users.invite, changing a teammate needs users.edit. By default that is the Owner and the Administrator of a supplier, and the Owner and Administrator of a customer business. Everyone else is sent back. Staff can change who holds these keys at /platform/permissions; the page and its buttons follow the next request.
• Inviting is limited to 20 invitations per hour per user. Buttons you cannot use are disabled with the reason ("Requires Administrator").

Roles you can assign#

The Roles and permissions tab opens with one sentence per role (what it is for), then the grid of what each role can do. The role selector list the roles of your organization's side with their current grants, read from the live matrix (names and grants change when staff edit them). Customer teammates are invited as Administrator, Buyer manager or Buyer. A Buyer sees only the applications and references they created; the other customer roles see the whole business's (the "Own" and "All" marks in the matrix). Staff may also create custom roles; an administrator assigns them from the role selector.

Single sign-on#

People who sign in through your company's single sign-on are marked "(SSO)" and "Set by single sign-on". Their role comes from your identity provider each time they sign in, so a role changed here lasts only until their next sign-in; a notice above the list says so, and the edit sheet repeats it. Change the role in the identity provider to make it stick. An SSO-managed membership cannot be removed here either; ask your IT administrator.

Ownership#

Every organization has one Owner. Only the Owner can hand ownership to another active member (the Ownership section, with a reason that goes into the audit trail; the Owner stays a member with their role), and nobody else can remove or demote the Owner. Everyone else sees who can change it. If the Owner has left or cannot sign in, contact VendorLogic support from the Owner's business email: staff confirm who you are before they reassign ownership. An Owner with no other active member is told to invite one first.

Inviting#

POST /v1/admin/users with name, email, role (and a customer role for customer teammates). The email must be deliverable. An Idempotency-Key header makes a retried click safe. Errors: 400 invalid input, 403 not allowed, 413 body too large, 429 too many invitations.

Changing access#

PATCH /v1/admin/users/:id accepts role, permissions (a list) and status (ACTIVE, DEACTIVATED, INVITED). An empty permission list means "use the role's cells"; role:<KEY> selects a matrix role; a list of permission keys replaces the role's cells for that person.

• A permission must be valid for the organization kind (400), and a role must fit the user's organization (403).
• Staff accounts cannot be changed here (403).
• A change records the audit event user.access_changed with before and after values, revokes the target's sessions so the change bites at once, and sends the "joined" email when a pending user becomes active.
• 409 means the account changed while you edited; reload.

Company names and email text never grant membership. Membership comes only from an invitation or an approval by an administrator.