You are setting up RelayLink for a small team and one shared login looks easier than accounts for every colleague. The operations lead gets one key, puts it in a common secret store, and everyone appears ready to send. RelayLink does not technically prevent that credential sharing. The setup works, but the identity is wrong.
For founders, agencies, departments, and internal product teams, the general answer is no: do not share one RelayLink account among several people.
One account makes one claim
A RelayLink account represents one person's email address and display name. Packages, contact requests, approvals, and threads speak from that identity.
If Maya and Luis share Maya's account, a recipient sees Maya's email and display name. RelayLink cannot tell whether Maya reviewed the package, Luis did, or an unattended process used their common credential. Both coworkers appear as the same sender because they authenticated as the same account.
That ambiguity is not repaired by putting initials in the note. The account still owns one contact list, one set of blocks, one inbox, and one correspondence history. A recipient deciding whether to trust the package should not have to infer which human was behind the shared login.
Several assistants for one person are fine
The boundary is the person, not the software. Maya can connect Claude, ChatGPT, and an agent framework to Maya's account. Those assistants are meant to share her inbox, contacts, and threads because they all act for her.
Give each integration its own OAuth connection or a named key issued from Maya's account page so she can disconnect or revoke one without disturbing the others. If she wants to move work between assistants, she can send a briefing to herself. The package remains attached to her identity and does not require a second account.
This is the useful distinction:
- One person, several assistants: one account can be appropriate.
- Several people, one assistant service: each person should authenticate separately.
- Several people, several assistants: each person keeps their own account and connects whichever assistants they use.
Give teammates their own identities
For a team deployment, each employee signs in as themselves. Two activated accounts need an accepted contact relationship before starting a new thread. If an external recipient has not activated an account, they can receive and reply by email without signing in. If they activate later, the cold thread they already joined remains open, while another new thread requires contact acceptance. A block stops either path.
The result is a clean chain: the sender's account identifies the person, the package records what they approved, and the recipient answers on the same thread. Teammates can still forward a conclusion or prepare a cross-team briefing. They simply do it as themselves.
A multi-user SaaS integration should follow the same model. Authenticate each person who connects the integration with OAuth where the client supports it, or keep a distinct named key for that person's integration. Do not place one service key behind many tenants and select the supposed sender from an application field.
Shared role mailboxes are a different product shape
Some workflows genuinely want interchangeable operators: support agents answering as help@, an on-call rotation speaking as one service, or an automated system posting status updates. A shared role identity may be appropriate there.
RelayLink is not designed as that queue or bot bus. It is designed for person-owned, human-approved correspondence. If the requirement is “any team member may act as the same sender,” RelayLink's personal account model is a poor fit unless one named person truly owns every approval.
A practical migration from one shared setup
Stop adding integrations to the shared account. Have each teammate sign in at the account portal, set the display name recipients should see, and connect their own assistant from the connect page. Move future correspondence to those identities; do not copy credentials between them.
Keep one person's multiple assistants together when that helps their workflow. Keep multiple people apart when authorship matters. How RelayLink keeps inboxes separate describes the technical boundary behind that recommendation.