Team

List org members, add them without an invitation email, change roles and remove them

Scopes: TEAM_READ to list, TEAM_MANAGE to change.

This exists so a partner can mirror its own user management into a client org - create the operator accounts from your product, not through Wexio's invitation flow.

orgTeamMembers

orgTeamMembers: [OrgTeamMember!]!

TEAM_READ

Lists the org's members. Takes no arguments.

Returns [OrgTeamMember!]!

Field	Type	Description
`id`	`String!`	The membership ID. Pass it to `updateOrgMemberRole` and `removeOrgMember`.
`userId`	`String`	The user ID. This is what `assignChatToOperator` takes.
`email`	`String`	The member's email.
`role`	`Role!`	`OWNER`, `ADMIN`, `EDITOR` or `AGENT`.
`status`	`OrganisationMemberStatus!`	`PENDING`, `ACCEPTED`, `DECLINED` or `REMOVED`.

id and userId are different values with different uses. Assignment needs userId; member management needs id. The type documents userId as "the id to pass to assignChatToOperator" for exactly this reason.

query Team {
  orgTeamMembers { id userId email role status }
}

addOrgMemberDirect

addOrgMemberDirect(input: AddOrgMemberDirectInput!): OrgTeamMember!

TEAM_MANAGE

Adds a member directly - no invitation email is sent, and the member is created already ACCEPTED. They can be assigned conversations immediately.

Arguments - input: AddOrgMemberDirectInput!

Field	Type	Required	Description
`email`	`String!`	Yes	The member's email address.
`role`	`Role!`	Yes	`AGENT` or `EDITOR` only - see the cap below.
`name`	`String`	No	Display name for the operator. Trimmed, up to 100 characters.

name only applies when the call creates a new user. If that email already has a Wexio account, the person's own name is kept and yours is ignored - their account is theirs, not yours to rename.

So pass it for genuinely new operators and do not rely on it to correct an existing name.

A key can only assign AGENT or EDITOR. ADMIN and OWNER are refused, on create and on re-role alike. A key must never be able to manufacture authority beyond its own scopes, so promoting someone to admin stays a dashboard action by an existing admin or owner.

mutation AddAgent {
  addOrgMemberDirect(input: { email: "ana@pizzeriaroma.com", role: AGENT }) {
    id
    userId
    role
    status
  }
}

{
  "data": {
    "addOrgMemberDirect": {
      "id": "6805d1a0b4d5e6f70123ab99",
      "userId": "6805d1a0b4d5e6f70123ab98",
      "role": "AGENT",
      "status": "ACCEPTED"
    }
  }
}

Because no email goes out, the member never gets a Wexio sign-in prompt from this call. If they are meant to log into the dashboard as well, handle that in your own onboarding - this mutation creates the membership, not a login journey.

On a tech-provider client org this is the only way in: inviteMember is refused there with "add members directly", and no Wexio email of any kind reaches a client org.

updateOrgMemberRole

updateOrgMemberRole(input: UpdateMemberRoleInput!): OrgTeamMember!

TEAM_MANAGE

Arguments - input: UpdateMemberRoleInput!

Field	Type	Required	Description
`memberId`	`String!`	Yes	The membership `id` from `orgTeamMembers`.
`role`	`Role!`	Yes	`AGENT` or `EDITOR` only.

The same role cap applies - a key cannot promote anyone to ADMIN or OWNER, and cannot change the role of someone who already holds one.

removeOrgMember

removeOrgMember(memberId: String!): Boolean!

TEAM_MANAGE

Removes a member. Returns true on success.

Arguments

Argument	Type	Required	Description
`memberId`	`String!`	Yes	The membership `id`, not the `userId`.

Conversations assigned to that member are left assigned to a member who is gone - unassign or reassign them first with assignConversationThreads.

orgTeamMembers

addOrgMemberDirect

updateOrgMemberRole

removeOrgMember

On this page