Skip to content

Move a connection to a new owner without re-authorizing it, and decide what happens to someone’s personal connections when they leave the organization.

Where to find it:

  • Connections → row actions → Manage access → the transfer icon next to Owner
  • Settings → People → Members → Remove from organization (offboarding dialog)

Credentials stay in place. You’re changing who owns the connection in Elaichi, not asking the product to sign in again. Toolboxes that already use the connection keep working after a transfer.

Ownership is one person

Every connection is owned by exactly one member. There is no team or organization owner: transfer changes owner_user_id and nothing else.

Who can reach a connection is a separate thing — grants, made by sharing it with a member, a team, or everyone at your organization (connection:share). A transfer never adds, removes, or widens a grant, and sharing never changes the owner. That separation is deliberate: an ownership move that silently handed everyone access would be the kind of quiet widening the access model exists to prevent.

To make a personal connection into shared infrastructure, share it. To hand it to a colleague, transfer it. To do both, do both.

Transfer and offboarding choices
flowchart TD
  Start["Personal connection"] --> Why{Why change owner?}
  Why -->|Hand it to a colleague| Transfer["Transfer → another member"]
  Why -->|Others need to use it| Share["Share → member, team or everyone"]
  Why -->|Member is leaving| Offboard["Offboarding dialog"]
  Offboard --> Action{Per connection}
  Action --> TPerson["Transfer to member"]
  Action --> Delete["Delete connection"]

Transfer a connection

  1. Open Connections and find the connection.
  2. Choose Manage access from its row actions.
  3. Click the transfer icon next to Owner, and pick the new owner — any member of the organization except the current owner.
  4. Confirm Transfer.

You'll know it worked when: the connection’s owner shows the new member, the access list is unchanged, and dependent toolboxes still run.

Transferring needs someone else in the organization to transfer to. If people beyond the new owner depend on the connection, share it with them as well — the transfer alone does not.

When someone leaves (offboarding)

Removing a member is where forgotten personal connections bite. Elaichi won’t let you delete someone and leave broken shared toolboxes behind.

  1. Open Settings → People → Members.
  2. Open the member’s menu → Remove from organization.
  3. Elaichi loads an offboarding summary: everything they own — connections (and which toolboxes reference each one), synthetic tools, toolboxes and templates.
  4. Connections used by shared toolboxes are flagged Used by shared toolboxes and list those toolbox names. Shared toolboxes and templates are flagged the same way.
  5. Either pick one person under Give everything to, or choose an action per resource, then confirm Remove member.

Offboarding choices (complete list)

Choice What happens Use when
Transfer to member Ownership moves to another member you select; credentials stay. Shared toolboxes keep working. Someone is taking over that account — the safe choice for anything others use.
Delete connection Connection (and vaulted credentials) are removed. Toolboxes that used it break. Truly personal; nothing else should keep using it.

There is no “transfer to organization” or “transfer to team” here, for the same reason there is none on the row: a transfer moves ownership only. If the team should keep using the account, transfer it to whoever will hold it, then share it with the team.

Toolboxes, templates and synthetic tools

The same dialog resolves the rest of their estate, and the rules differ by resource:

Resource Choices Default
Toolbox / template, shared with anyone Transfer to member, or delete None — you must choose. Only an owner can delete or transfer one, so a shared row left behind is unmanageable by everybody, forever.
Toolbox / template, private Transfer to member, or delete Delete — nobody else could ever reach it.
Synthetic tool Delete (only option) Delete — one can’t be shared or transferred, and it runs on the author’s own connections. You confirm the ones another person’s toolbox pins.

Give everything to picks one successor for every transferable resource at once; per-resource choices still override it. There is no bulk delete.

If the member owns a very large estate, the first Remove member may report that some of it was resolved and more remains — the work done is kept, the member stays, and you confirm again to continue.

Defaults in the dialog

Situation Default action
Connection is referenced by shared toolboxes (needs_resolution) Transfer to member
Connection is not referenced Delete connection

Change either before confirming. If you pick Transfer to member, you must also pick the member — the remove button stays disabled until every row is complete.

If you try to leave a referenced connection — or any shared toolbox or template — unresolved, removal is refused (connections_need_resolution, toolboxes_need_resolution, templates_need_resolution). Unreferenced personal connections, private toolboxes and private templates are cleaned up with the member.

You can’t remove yourself from this screen. The last Org Owner can’t be removed until someone else is an Owner.

Good to know

  • Deleting a connection breaks every toolbox that used it. Read the “Used by” list before choosing Delete.
  • Transfer does not rotate credentials or re-run OAuth.
  • Offboarding lists everything the leaving member owns, shared or not: connections, synthetic tools, toolboxes and templates. A shared connection may be left as it is — its grantees keep reaching it, and an admin can still move it afterwards — but a shared toolbox or template may not, because nothing but ownership can move or remove one.
  • Share the systems other people depend on before someone leaves, so day-of removal is a quiet ownership move rather than a scramble.