Team access and roles

Understand the actual permissions#

Team invitations are available on Business and Scale. Full portal workspace management is authorised for active Owner and Admin memberships. A Member invitation does not grant access to the main workspace management views, including Knowledge, Websites, Conversations, Analytics and Billing.

Use Admin when a teammate needs to manage the assistant. There is no read-only conversation-review role in the portal.

Create and share an invitation#

1. Open Team as an owner or admin.
2. Under Add a teammate, enter the person's Work email.
3. Choose Member or Admin, then select Create invitation.
4. Select Copy invitation link and send the link directly to that person.

Creating the invitation displays a link; it does not automatically send an invitation email. Pending invitations appear in Current team, together with their role and expiry.

Accept using the invited account#

The recipient must sign in to a Reesponder account with the exact invited email address. Opening the link while signed in as a different colleague cannot accept it. If the recipient does not yet have account credentials, contact Reesponder for onboarding; the invitation itself is not a public account-registration form.

After acceptance, reload if necessary and select the invited workspace when a workspace selector appears. The accepted role determines what the server permits. If the recipient can sign in but cannot manage that workspace, check whether they were invited as Member rather than Admin.

Replace or revoke an invitation#

Invitation links expire after seven days and can be used only while valid and not revoked. Creating a replacement invitation for the same workspace and email revokes its previous pending invitation. Use the newest link.

Choose Revoke beside a pending invitation to prevent acceptance. If the workspace no longer has Business or Scale access, the server can refuse acceptance even if the link has not reached its date expiry. Restore the required plan or contact the workspace owner rather than sharing credentials.

Remove access and handle failures#

Only the owner can remove a non-owner teammate. Owners cannot be removed through the team's Remove control. Removal revokes membership for this workspace; it does not delete the person's account or their membership in other workspaces.

The portal has no role-edit or ownership-transfer control. If a role needs changing, arrange the change with the owner or contact Reesponder. For invitation errors, check the plan, existing team membership and exact email. Keep invitation links private: revoke any pending link that was shared with the wrong recipient.

Worked example: a contractor only needs an answer review#

A business asks a contractor to review the wording of a few public-policy answers. Admin would permit broad workspace management; Member does not provide a read-only version of the main management views. The owner therefore decides whether full management is actually justified before sending an invitation.

For a review that does not need account configuration, the business can use an appropriate controlled review process, such as a private test shared only with its intended reviewer. That link also carries access information and is time-limited, so it must be handled deliberately. Do not promise that a Member invitation limits somebody to a specific Conversations screen; that granular review role is not available in the current portal.

Keep an access record with an acceptance result#

Record the intended account email, role, approving owner and responsibility. After the person accepts, check Current team and have them verify their permitted task using their own credentials. Do not retain usable invitation links in a public handbook as evidence of the grant.

Review the list when responsibilities change and account separately for pending invitations. Revoking a pending invite and removing an active membership address different states. Ownership changes need their own supported process, while a display-name edit or password reset cannot transfer workspace ownership. The offboarding section below covers the external responsibilities a membership change does not automatically resolve.

Recognise the limits of delegated management#

Owner and Admin are management roles, not feature-by-feature permission bundles. Before granting Admin, consider that the colleague can work in the main workspace areas, including Knowledge, website settings and Billing. A contractor who needs to adjust a sentence can therefore receive more authority than their narrow task alone requires. The current portal does not offer a custom permission editor to turn that grant into “Knowledge only”.

Choose a practical working arrangement with the owner. If management access is appropriate, agree which sources and websites the colleague maintains and how changes are checked. If it is not appropriate, an authorised maintainer can carry out the reviewed correction. Written responsibility helps prevent mistakes, but it is not a server restriction limiting an Admin to one topic or website.

Use individual accounts for ongoing administration. This makes it possible to remove one colleague's membership without relying on a shared owner password. Keep the owner involved in supported removals and ownership questions; Admin invitation authority does not make the Admin the owner. Never use a visitor's contact form, an Action verification email or a website installation token as a substitute for team account access.

Avoid account-email and delivery mistakes#

The portal creates a link that you copy; it does not automatically email the invitation for you. Agree on the recipient's account email before creating it, then use a suitable private channel to deliver the link. A pending invitation with a correctly spelled address can still remain unaccepted if nobody actually sent the copied link. Inspect Current team after the recipient accepts rather than assuming creation completed their onboarding.

An alias mismatch is another common failure. A person might receive mail at [email protected] but sign in as [email protected]. Those are different account addresses for invitation matching even when one forwards to the other. Ask which existing Reesponder account they intend to use. Invite that exact account or have them sign in to the genuinely invited account. Repeatedly clicking the same link while signed into the wrong account does not correct the mismatch.

If the wrong address was invited, revoke the pending invitation and create the correct one. A replacement invite for the same email revokes an earlier unused link, so the recipient needs the latest link rather than an old bookmark. Keep the seven-day expiry in mind for delayed onboarding. Do not preserve usable invitations in a public team handbook or share them with several people. Your onboarding record can keep the intended account, role and acceptance result without retaining a credential that would allow membership acceptance.

Check external responsibilities when access changes#

When a person leaves, review active membership and outstanding invitations. The Owner can remove an active non-owner member from this workspace; authorized managers can revoke pending invitations. Check the resulting Current team list. Removing one membership does not delete the person's unrelated memberships elsewhere and does not cancel the business subscription. A team change needs evidence of the intended access change, not an assumption that every account-related record was erased.

Look for operational dependencies the person maintained: the handoff destination mailbox, source-update responsibility, provider credentials your business owns and billing contact information. Membership removal does not automatically transfer these external responsibilities. If a shared mailbox is retired, change the configured destination and test a permitted handoff. If an Action endpoint uses a credential controlled by the departing person, handle that credential through the system that owns it rather than assuming the workspace role change rotated it.

Use the replacement colleague's own account. Ask them to perform a permitted maintenance check after joining, so you know the role is usable. Do not test access by asking for their password. If removal fails, confirm the acting user's Owner authority and that the target is a non-owner. If the business needs an ownership transfer, contact support instead of attempting to remove its only owner. Complete offboarding with separate checks for membership, pending invites and the operational systems remaining outside Reesponder.