RevOps Playbook: User Permissions, Profiles, and Governance for HubSpot–Salesforce

Granular permissions and clear governance safeguard your integration from accidental edits, mass updates gone wrong, and data privacy violations. This playbook describes a pragmatic model for access, profiles, roles, and approval workflows across HubSpot and Salesforce so your RevOps team can ship changes confidently while protecting data integrity and privacy.

We will define accountable ownership, the minimum viable permission sets for typical personas, and a lightweight change-management process that prevents chaos without slowing down the business. The outcome: safer systems, fewer incidents, and faster iteration.

Who This Is For

RevOps leaders, HubSpot/Salesforce admins, and security or IT partners who manage access controls, audit requirements, and process changes across the GTM stack.

Guiding Principles

Least privilege: grant only what is required to perform the role.
Separation of duties: no single user can both approve and deploy high-risk changes.
Auditability: all high-impact changes are reviewable and attributable.

Role and Permission Design

Build a small, composable set of roles that cover 80–90% of use cases. Avoid bespoke profiles per person.

Common Personas

Sales reps and SDRs: read/write on their records, limited edit on shared fields, no schema-level changes.
Sales managers: reporting across teams, approval for ownership changes.
Marketers: campaign and asset creation in HubSpot; limited edit rights in Salesforce.
RevOps admins: configuration and integration management, controlled via change requests.

Sensitive Fields and Objects

Email opt-out, PII, consent: editable by a narrow group; changes logged.
Lifecycle and lead status: write permissions limited; workflows enforce correct transitions.
Opportunities: edit rights for owners and managers; restricted access to forecast fields.

Change Management Workflow

Treat CRM changes like product changes—small, reviewed, and reversible.

Propose: create a change request describing the goal, fields affected, and dashboards impacted.
Review: peer review by another admin; security review when PII is involved.
Test: implement in sandbox with sample data and edge cases.
Deploy: schedule during low-traffic windows; communicate owners and rollback steps.
Verify: monitor for errors, outliers, and user feedback.

Integration Guardrails

Protect cross-system flows with these controls:

Field Ownership Registry

Maintain a versioned registry declaring system-of-record, sync direction, and tiebreakers. Enforce through profiles and validation rules to prevent unauthorized writes.

API Access

Use dedicated integration users with scoped permissions and API-only profiles. Rotate credentials, monitor API error spikes, and disable unused integrations.

Data Privacy

Enforce consent propagation from HubSpot to Salesforce. Mask or restrict access to sensitive fields, especially for support or contractor roles.

Incident Response

Incidents still happen. Reduce blast radius and recovery time.

Pause: disable the affected workflow or sync.
Diagnose: identify recent changes, review error logs, and compare against the field registry.
Remediate: backfill or revert values; communicate affected teams and expected timelines.
Learn: add safeguards (validation, tests) to prevent recurrence.

Anti-Patterns to Avoid

Granting admin to unblock one urgent request—temporary access becomes permanent.
Running large, unreviewed mass updates in production.
Allowing workflows to write governance fields owned by another system without checks.
Sharing integration credentials across tools.

FAQ

How do we balance speed and safety in RevOps?

Adopt small, frequent changes with peer review. With a simple template and weekly release window, changes move quickly without risky big-bang deployments.

Who should own the integration user accounts?

RevOps should own them, with security oversight. Use separate users for each integration, scoped to minimum permissions and logged.

What’s the easiest way to audit risky changes?

Keep all mapping and workflow definitions in a repo. Require pull requests and reference IDs in change logs inside the CRMs for traceability.

How do we prevent accidental edits of sensitive fields?

Combine permission sets and validation rules. Only allow writes through specific workflows or roles; log any bypasses and alert the admins.

How often should we review access?

Quarterly at minimum, and immediately when roles change. Remove unused accounts and expire credentials regularly.