Updating Email Domains and Managing Team Members in Vitally
Inviting Team Members and Auto-Created Users
Missing "Invite a Teammate" Button?
If the option to invite a new team member is missing, SSO is enabled. Team members can only be added via the SSO provider.Invitation Expiry
When a new team member is invited, the invite link expires after a certain period. If they don't accept it in time, an admin must resend the invitation.
Auto-Created Users
Vitally may automatically create a placeholder team member when it resolves an internal person's email while syncing ownership or key-role data, and that email doesn't yet belong to an existing Vitally user. If the person is later invited, this placeholder converts into an active user, transferring all associated data (accounts, tasks, projects, etc.).
Common origins include:
HubSpot: an owner referenced by CRM data or synced activities (tasks, notes, emails/meetings), or a configured owner/key-role field
Salesforce: a referenced Salesforce User (e.g. CSM/AE/owner resolution), or the owner of a synced task or note
Zendesk: an admin or agent encountered while syncing Zendesk data
Jira: an issue assignee, or a Jira-user lookup used for Jira Connect/impersonation. This can be limited to your configured owned domains, see Settings > Integrations > Jira
Public REST API: an Account/Organization update made via the API, if the updated trait is mapped as that Account/Organization's Key Role email field
Any connected data source that writes an Account or Organization email trait mapped to a Key Role, for example Segment, CSV, CRM, or warehouse-style imports
Integration Source: Unknown
The Team Members table shows an Integration Source of Unknown when a Key Role email is created or changed by something other than a connected data-source integration. This includes:
A manual, in-app Account/Organization edit, or an Explorer bulk trait update, when the edited trait is the Key Role email field. (This does not apply to updates made via the Public REST API, those retain a Public API source link.)
A Playbook Update Custom Trait action, but only when the trait it writes is mapped as a Key Role email field
A formula trait, legacy calculated trait, or trait reprocessing job, but only when its output trait is mapped as a Key Role email field. Key role configuration changes enqueue reprocess jobs that backfill these
Any other internal flow that runs trait processing as a Vitally user, a Playbook, a custom field, or with no connected integration context, rather than through a data-source integration
Note: Integration Source reflects the oldest integration link a team member has on record, not necessarily how they were created. A team member created through an Unknown path with no retained link will show Unknown, and one created via a connected integration will show that integration even if it's later changed through one of the paths above.
Updating a Team Member's Name, Email, or Job Title
Admins and leaders can update a team member's name, email address, or job title directly from Settings > Team Members > Manage.
To update a name: Hover over the name and click the pencil icon to edit it, the same way trait cells are editable.
To update an email address: Click the email field. A confirmation modal appears before the change is saved.
If SAML SSO is not enabled: a warning advises you to notify the team member of the change, as it may affect their ability to log in.
If SAML SSO is enabled: a stronger warning indicates that if the email is not also updated in your identity provider, the team member will lose access to Vitally. The confirm button is styled as a destructive action.
If the email you enter is already in use by another Vitally user, an error is shown inline.
To update a job title: Click the Job Title field and enter the team member's title. A team member's job title is included in the default context Vitally AI uses, so keeping it current helps AI responses reference the right role.
 |
 |
|
Note: Integrations that use email for matching (such as Salesforce) will reflect the updated email. Because emails must be unique in both systems, duplicate conflicts are unlikely but worth verifying after making the change.
Migrating Email Domains for SSO Clients
When your organization is moving to a new email domain, or moving to a new email domain and a new email provider at the same time, follow the steps below to avoid duplicate profiles and interrupted syncing.
Domain and Email Provider Migration (e.g. Gmail to Outlook)
Applies to: migrations where both your email domain and email provider are changing. Playbook and fallback sender behavior in this scenario is different from a domain-only move, see Domain-Only Migration below if your provider is staying the same.
Update login emails
Each team member's Vitally login email needs to be updated to the new domain before your SSO provider starts sending it, otherwise you'll end up with duplicate profiles. This can be actioned directly from Settings > Team Members > Manage (see Updating a Team Member's Name, Email, or Job Title above).
This needs to be done all at once, with all users logged out of Vitally, to avoid duplicate profiles:
Users shouldn't log in with the new SSO NameID before the account email is updated.
Users shouldn't log in with the old SSO NameID after it has been updated.
Add the new domain under Settings > Security > Domain Exclusion. This is what stops internal emails and meetings from syncing in as conversations. Any Admin can add it.
Running two email providers side by side
Since Gmail and Outlook are separate connections in Vitally, both can run at the same time. Connect the new provider under Settings > Email & Calendar for a pilot group, and keep the original provider connected until sending and calendar sync are confirmed working. There's no need to move everyone at once.
Note: If both inboxes have already been synced internally before starting a pilot, duplicate emails may import into Vitally.
Before disconnecting the old provider
Take stock of anything currently sending from the old provider, both Playbooks and one-off outbound messages. These don't switch over automatically when the login email changes:
A Playbook's sender is set to a specific channel (Gmail, Outlook, etc.), not tied to the email address. If a key role is set to send via the old provider, it stays that way until someone manually changes it.
Fallback senders work the same way. If the fallback sender currently resolves through the old provider, that needs to be manually reselected too.
Pending messages or Playbook actions set to send from the old provider need to be updated to send from the new one first. Vitally removes the old provider as a sender option on disconnect, and anything still pointing at it will fail to send.
Historical data
Disconnecting the old provider doesn't delete anything. Historical conversations stay exactly where they are.
Domain-Only Migration (Same Email Provider)
Applies to: migrations where your email provider is staying the same and only the domain is changing. If you're also switching providers, use the Domain and Email Provider Migration steps above instead, playbook and fallback sender behavior differs.
Follow the same login email update steps described above: update each user's Vitally login email to the new domain, do it all at once with users logged out, and add the new domain under Settings > Security > Domain Exclusion.
Since the provider isn't changing, there's no dual-connection period. Vitally only supports one connected inbox per provider per user, so a mailbox on the new domain can't sit alongside the old one — reconnecting under the new address updates the existing connection rather than adding a second one.
Each user reconnects their Mail and Calendar under Settings > Email & Calendar using their new address once it's live. There's a brief window between disconnecting the old and reconnecting the new where that user's mail won't be syncing, so it's worth doing this promptly rather than leaving it for later.
Because the provider itself isn't changing, Playbooks and fallback senders don't need updating. A Playbook's sender is tied to the channel (Gmail or Outlook) plus the VitallyUser record, not the raw email address, so sends continue to route correctly through the same channel once the login email is updated.
Historical data isn't affected by reconnecting. Historical conversations stay exactly where they are.