Outreach User Management Guide

• Model type: hybrid
• Description: Outreach uses a combination of predefined system roles (Admin, Manager, User) and configurable permission profiles. On higher-tier plans, admins can create custom permission profiles that control granular access to features such as sequence creation, prospect import, reporting, and data export. Role assignment determines baseline access; permission profiles layer additional restrictions or grants on top.
• Custom roles: Yes
• Custom roles plan: Professional or Enterprise (exact tier for custom permission profiles not publicly confirmed; verify with Outreach sales)
• Granularity: Feature-level: sequence management, prospect ownership, reporting access, call recording, data import/export, and integration access can each be toggled per permission profile.

1. Log in as an Admin and navigate to Settings (gear icon in left nav).
2. Select 'Users' from the Settings menu.
3. Click 'Invite User' or 'Add User' button.
4. Enter the new user's first name, last name, and work email address.
5. Select the appropriate Role (Admin, Manager, or User).
6. Optionally assign the user to a Team and apply a Permission Profile.
7. Click 'Send Invite'. The user receives an email invitation to set up their account.
8. User accepts the invite and sets a password (or authenticates via SSO if configured).

Required fields: First name, Last name, Work email address, Role

Watch out for:

• Inviting a user immediately consumes a licensed seat; seat count is reflected in billing at next cycle.
• If SSO is enforced, users must authenticate via the configured IdP; password-based login may be disabled.
• Email domain must match the org's configured domain if domain restrictions are enabled.
• Users do not have access until they accept the invitation; pending invites still occupy a seat in some contract configurations-verify with your Outreach account team.
• SCIM provisioning (Enterprise) bypasses manual invite flow; mixing manual and SCIM provisioning in the same org can cause duplicate or conflicting user states.

• Can delete users: No
• Delete/deactivate behavior: Outreach does not permanently delete user accounts. Admins can deactivate (disable) a user, which revokes login access and removes the user from active seat counts. The user's historical data, sequences, prospects, and activity logs are retained and remain accessible to admins. Deactivated users cannot be fully purged from the system through the UI.

1. Log in as an Admin and navigate to Settings → Users.
2. Locate the user to be deactivated using search or the user list.
3. Click on the user's name or the action menu (three dots / ellipsis) next to their record.
4. Select 'Deactivate User' (or 'Disable User' depending on UI version).
5. Confirm the deactivation in the dialog prompt.
6. The user's session is terminated and they can no longer log in. Their seat is freed for reassignment.

Watch out for:

• Deactivation does not automatically reassign owned prospects or active sequences; admins must manually reassign to prevent orphaned records.
• Active sequences running under a deactivated user's account may pause or stop sending; review and reassign before deactivating.
• CRM integrations (Salesforce, HubSpot) connected under the departing user's OAuth token will break; re-authenticate under an active admin account.
• On annual contracts, deactivating a user mid-term typically does not reduce the billed seat count until renewal; confirm with your Outreach account team.
• SCIM-provisioned users deactivated via the IdP are deactivated in Outreach automatically, but data reassignment still requires manual admin action in Outreach.

• Where to check usage: Settings → Users (shows active vs. deactivated users and total seat count); billing seat totals visible in Settings → Billing or via your Outreach account team.
• How to identify unused seats: Filter the Users list by 'Last Active' date in Settings → Users to identify users who have not logged in recently. No native automated unused-seat report is publicly documented; admins must manually review last-login data.
• Billing notes: Outreach sells on annual contracts. Seat counts are typically locked for the contract term; adding seats mid-term is prorated, but removing seats generally does not reduce billing until renewal. Enterprise contracts (200+ users, multi-year) have been reported with significant list-to-actual price variance. SCIM provisioning and SSO are available on Enterprise tier and must be configured as separate applications in the IdP.

Outreach sells on annual contracts, so seat costs are locked for the term. Adding a seat mid-contract is prorated; removing one does not reduce billing until renewal.

Inviting a user consumes a licensed seat immediately, and pending invites may still occupy a seat in some contract configurations - confirm this with your Outreach account team before bulk-inviting.

For large deployments, the gap between list and actual contract price can be substantial, but no specific discount rates can be stated here beyond what is publicly reported.

Every app in your stack carries offboarding risk, and Outreach compounds it: deactivating a user does not automatically reassign their active sequences or owned prospects. Admins must manually clean up orphaned records before or after deactivation to avoid pipeline gaps.

The most consistent admin complaint is post-offboarding cleanup: deactivated users leave behind active sequences and owned prospects that must be manually reassigned.

A second recurring issue is silent CRM breakage - when the user whose OAuth token authenticated the Salesforce integration is deactivated, sync fails without an obvious alert, causing data gaps that surface later.

Admins also flag the non-standard IdP setup: SSO and SCIM must be configured as two separate applications in the identity provider, which differs from most SaaS tools and causes confusion during initial rollout.

There is no native report for identifying inactive seats; last-login data must be manually reviewed in the Users list.

Common complaints:

• Admins report that deactivating a user does not automatically reassign their active sequences or owned prospects, requiring significant manual cleanup after offboarding.
• Users and admins note that mid-contract seat reductions are not honored; billing continues for deactivated seats until annual renewal.
• Community members report confusion around the requirement to configure SSO and SCIM as two separate IdP applications, which is non-standard compared to other SaaS tools.
• Admins have noted that there is no built-in report or dashboard for identifying inactive or unused seats; last-login data must be manually reviewed in the Users list.
• Some admins report that CRM (Salesforce) sync breaks silently when the user whose OAuth token was used for the integration is deactivated, causing data sync gaps that are not immediately obvious.
• Community feedback indicates that custom permission profiles and granular role configuration are not well-documented in the public help center, requiring support tickets or CSM involvement to configure correctly.

SCIM provisioning is gated behind the Enterprise plan and requires SSO to already be active. If your org is on Standard or Professional, every app lifecycle event - onboarding, role changes, offboarding - is a manual admin task. For orgs with high rep turnover or frequent territory changes, that overhead compounds quickly.

The Admin role grants org-wide access to all prospect and sequence data, including records owned by other reps. Assign it narrowly. Manager visibility is scoped to their assigned team only; cross-team oversight requires Admin elevation.

Bottom line

Outreach's manual user management is functional but carries meaningful operational risk at scale. Deactivation does not cascade - sequences pause, prospects orphan, and CRM sync can break silently - so every offboarding requires a checklist, not just a click.

Seat costs are locked annually, so unused licenses bleed budget until renewal.

Orgs that can reach Enterprise tier and invest in the dual-app IdP setup will recover most of that overhead through SCIM automation; those below that tier should build explicit offboarding runbooks to avoid recurring cleanup debt.