All plan types/levels | |
Permissions | Owners and Creators |
Platform(s) | Web/Browser, Mac app, and Windows app |
Before leaving my company/organization, what should I consider as a workspace, base, or interface Owner?
If you're a workspace, base, or interface Owner planning to leave your company or organization, consider how the following areas and will impact your collaborators:
Native automations
Native automations are workflows—like When a record is created trigger > Update record action—that feature trigger and action steps located entirely within Airtable.
Problem: When no one transfers a native automation before the Owner is deactivated, the automation failure notifications default to sending to the workspace's deactivated Owner until a new collaborator toggles the automation off and the back on again.
Solution: To transition native automations to another base collaborator, toggle the automation off and back on again—transitioning ownership of the automation and ensuring the failure notifications go to the new Owner.
External/integrated automations
External or integrated automations—like Send a Slack message—incorporate triggers or action steps that exists outside Airtable and involve API calls to an external source/use of personal access tokens (PATs).
Problem: External or integrated automations fail when an Owner's account is deactivated from the associated base to safeguard from previous collaborators attempting to access workspaces, bases, and interfaces.
Solution: Collaborators can rebuild their automations or replace their accounts in the integrated trigger/action steps after an automation fails.
Native syncs
Note
Sync Owners should invite collaborators to take over the sync table as collaborators to both the sync's source and target bases to prevent permission issues when attempting to reconnect the sync in the target base.
A native sync—like Configuring a sync—is a sync between Airtable bases.
Problem: Any synced tables created by a now-deactivated Owner will stop updating. This means the base and workflow schema remain intact because the synced table hasn't been deleted, but needs to be reconnected to start resyncing.
Solution: Collaborators can reactivate the sync to restart the sync.
External and sync integrations
External and sync integrations—like Jira, Emailed data, or Salesforce—are any synced tables whose source is an external service.
Problem: When a sync Owner for an external account is deactivated, the sync integration stops updating.
Solution: We recommend that organizations build their integrations with a service account—an email address (like "team@exampleairtable.com")—that can function as an Airtable "collaborator" who can access the necessary reports and files in your external sources
Admin management
Before an account admin leaves your organization, we encourage them to add at least one additional collaborator as an admin to help manage it and ensure the organization can be managed after the deactivated Owner is gone.
Workspace, base, and interface ownership
By ensuring another collaborator has Owner permissions, all bases and interfaces within that workspace will continue to have a collaborator who can help manage collaboration and access.
We encourage workspace Owners to transfer workspace ownership to another collaborator by upgrading their permission level to Owner before leaving the company.
Owners can can add an additional Owner directly to their workspace to help ensure data is transitioned to a new team member.
Enterprise admins can transfer workspace ownership via the “Workspaces tab” of the admin panel.
FAQs
Are downstream bases impacted when a native sync stops updating after the Owner leaves an organization or company?
The sync connection breaks when a sync owner leaves, but the table remains intact and doesn’t sync in new data.
A native sync is a sync between Airtable bases.
When a user is deactivated or leaves a company, the synced table they created will stop updating while the app and ecosystem schemas remain intact.
If the sync Owner leaves a company or organization, the sync will stop working until a user with access to data in both bases—the source and the destination—reactivates it.
While the sync is deactivated, the data remains in the table, and the ownstream bases are not impacted and will continue to sync with the same data.
Can broken emailed data sync integrations be transferred to a new Owner after the original Owner leaves an organization or company?
No. While there isn't a way to transfer emailed data sync integrations after the Owner leaves an organization or company, we recommend the following options:
Open your Airtable home screen.
Open the base containing the emailed data sync integration.
Click the arrow icon to the right of the table’s name, storing your emailed data sync integration.
Click Update sync configuration.
The email associated with your emailed data sync integration is the long email address to the right of the “Email:” section.
Click the clipboard icon to copy that email address.
Add that email address to table description so it can be accessed publicly by your team’s collaborators.
As long as collaborators have that sync inbox email address, they can continue to send data into the synced table.
If this isn't possible, we recommend that a collaborator take over this sync. In the synced table, if a new sync owner selects Sync configuration settings and clicks Add records from another source, they can add a secondary Emailed Data sync integration on top of the table.
Alternatively, they can email a CSV to the new inbox with a dataset identical to what's currently in the table. The system can create new records for this new sync source in the table, and the team can easily copy and paste any values from manually added fields (like linked record fields) from the old synced records to the new synced records. From there, the user can remove the original Emailed data sync source from the table's settings, deleting those original, extra synced records.