Removing a Member
When someone leaves the organization -- a contractor finishing a project, an employee changing roles, a teammate moving on -- their work doesn't go with them. It transfers to another member of your choice, the heir, before the membership is removed.
This is an admin-only action and the platform walks you through every consequence before you confirm.
What gets transferred
When you remove a member, these belong to them and transfer to the heir:
- Projects they created
- Workflows they created
- Triggers they created (schedules, webhooks, app-event triggers)
- Workflow templates they exported
- Private credentials they created (with a caveat -- see below)
- Share attributions -- shares they granted to others continue, now attributed to the heir
These get destroyed instead of transferred:
- Share rows where the departing member is the recipient -- their access to other people's work ends when their membership ends. Those resources don't transfer to the heir; they stay with their original creators.
These are left alone:
- Workflow runs the member triggered -- audit trail is preserved exactly as it happened. Historical attribution doesn't change.
The removal flow
Steps
- Go to Settings → Members.
- Find the member in the list and click Remove.
- The confirmation screen shows an impact summary -- how many projects, workflows, triggers, templates, and private credentials they own -- and a heir picker listing every other active member of the org.
# TODO screenshot: Member removal confirmation screen with impact summary (counts) and heir selector
- Pick an heir. Admins and owners are listed first because they're the most common heirs, but any active member is eligible.
- Click Confirm removal. The transfer and the removal happen together, in a single atomic step -- you cannot partially remove someone.
- The success message summarizes what transferred: e.g. "Jane Doe removed. Transferred: 3 projects, 7 workflows, 2 triggers."
If the member you're removing also had no other org memberships, their ORQO account is closed at the same time.
The private credentials catch
Private credentials are the one wrinkle in the transfer.
A private credential is an API key the departing member added under their own settings -- only they have ever seen the actual secret value. When you transfer ownership of that credential to the heir, the secret itself does not become known to the heir. The heir inherits the ownership row, not the secret.
Practically, you have two options for each affected credential:
- Rebind -- the heir replaces the secret with their own key. The workflows that depend on that credential keep working under the heir's own authority.
- Remove -- delete the credential. Workflows that referenced it will fail at the next run until they're rebound to a different credential.
After the removal completes, the success flash will warn you when private credentials transferred:
"3 private credential(s) transferred to Bob Smith, but the heir doesn't know the secret values. Review under Settings → Credentials and rebind or remove."
Bob should then open Settings → Credentials, find the inherited rows, and either supply his own secret or delete them.
# TODO screenshot: Settings → Credentials view showing an inherited credential with a "Rebind" prompt
What if there's no obvious heir?
Pick any active admin. They can subsequently re-share the transferred resources with other members, or use the (forthcoming) ownership transfer flow to hand individual resources to other appropriate owners.
Don't worry about picking the "wrong" heir -- the transferred resources can be re-shared or re-exported as templates immediately, so the cost of choosing wrong is small.
You can't remove the owner
The organization owner cannot be removed via this flow. If the owner is leaving, they must first transfer ownership to another member, and then the new owner can remove the prior owner like any other member.
You also can't remove yourself this way -- to leave an organization you're a member of, use the Leave organization action in the Danger Zone of your own account settings.
What gets logged
The removal is recorded in the activity feed so admins can see who was removed, when, and by whom.
Learn more
- Activity Feed -- the audit trail
- Add a Credential -- if you need to rebind an inherited credential
- Roles: Member, Admin, Owner