How do I manage multiple user accounts and assets during a mass email domain migration?
How do I manage multiple user accounts and their assets during a mass email domain migration activity?
How do I manage multiple user accounts and their assets during a mass email domain migration activity?
Managing Multiple User Accounts & Assets During a Mass Email Domain Migration When your organization changes its email domain (e.g., @oldcompany.com → @newcompany.com), you need to update every affected user account while making sure their owned assets (pipelines, accounts, tasks, projects) stay intact. Here's how to approach it: 1. Inventory Current Users and Their Assets From Admin Manager → Users, you can: - Download a CSV list of all users — this gives you emails, names, roles, group memberships, and access types, which is essential for planning a bulk update. - Filter/search by role or access type to scope exactly which accounts are affected by the domain change.
Important: In SnapLogic, every asset has an owner tied to a user account. This is why the migration/update of accounts must be carefully sequenced — you don't want to orphan ownership of pipelines, projects, or accounts.
2. Update Each Account's Email (Core of the Migration) For a handful of users, you can edit accounts manually in Admin Manager (click a row to edit details). For a mass migration, scripting against the public APIs is the recommended path: - Get a user (GET /api/1/rest/public/users/{email}) — retrieve current profile and org membership. - Create/Update a user (POST or PUT /api/1/rest/public/users) — note the API accepts fields like email, first_name, last_name, organization, administrator, allow_password_login, ui_access, etc. - Since emails are usually the unique identifier, a domain-wide email change often requires creating a new account record under the new email and transitioning ownership, since directly editing the primary email key may not be supported for all account types — plan to validate this per account type (user, team, service account). 3. Handle Asset Ownership Carefully - If you delete an old account during cleanup, note that ownership of all its assets automatically transfers to the Environment admin who performs the deletion — not to the new/replacement account. You'll likely need a follow-up step to reassign ownership to the correct new user. - For users and groups specifically, SnapLogic recommends this sequence (especially relevant if domain change coincides with environment/org changes): 1. Pull the full list of users and the groups they belong to (via CSV export or the Groups/Members APIs). 2. Re-create or update groups first. 3. Re-create or update user accounts and reassign group memberships. 4. Validate Allowlists and Access Policies - SnapLogic validates new users against an email domain allowlist during account creation. If the new domain isn't allowlisted, user creation will be blocked — update the allowlist before running your mass update/migration script. - If your org uses SSO or MFA, check whether login configurations also need to be updated to reflect the new domain (SSO credentials/certificates are not automatically migrated and require manual reconfiguration). 5. Bulk Operations Support - The Admin Manager UI supports multi-select actions: you can select multiple users and bulk-delete, modify application access, or update authentication methods (password/SSO/MFA) — useful for cleanup after the domain cutover, though direct bulk email-renaming via UI isn't a listed capability; scripting via the public APIs is the more scalable route for the actual domain swap.
6. Recommended Overall Flow 1. Export current users/groups (CSV or API) for a full inventory and rollback reference. 2. Update allowlist to include the new domain. 3. Script the account updates using the public Users/Groups APIs, mapping old emails → new emails. 4. Reassign any orphaned asset ownership resulting from deletions. 5. Reconfigure SSO/MFA settings tied to the new domain, if applicable. 6. Validate via the Admin Manager Users screen (role, access, group counts, login type) and spot-check asset ownership on key projects/pipelines. 7. Communicate the cutover to downstream teams, especially if task URLs or notification configs reference user emails. If this activity is part of a larger environment migration (not just a domain rename), SnapLogic's full migration playbook and CSM/PS-assisted migration tool are typically used, since account re-encryption, trusted environment setup, and asset validation become more involved at that scale. Let me know if that's the case and I can go deeper into that playbook.