Update Heap Analytics Roles for the collaborator | OpsBlu Docs

Update Heap Analytics Roles for the collaborator

Adjust organization or project permissions for the collaborator as workstreams change.

Update Access & Roles

Use this guide when Heap permissions or project access need adjustment. Updating access allows you to modify roles without removing and re-adding users, which preserves their activity history, autocaptured event data, and configured assets.

Role and permission changes take effect immediately in Heap. Users may need to refresh their browser to see updated permissions, but no logout is required.

When to Update Access

Update user access when:

  • A role changes: Analyst promoted to Product Manager; Admin stepping down to Member
  • Project scope expands or contracts: New products launch; agency wins/loses client; team member takes on additional environments
  • Module access changes: Organization purchases Heap Govern, Illuminate, or Activate modules requiring new permissions
  • Temporary elevation: User needs Admin for one-time task (tracking plan deployment, integration setup)
  • Security or compliance requirement: Audit reveals user has more access than needed; implementing least privilege
  • Organizational restructure: Team mergers, department changes, or reporting line shifts
  • Environment changes: Production, staging, development environment access needs adjustment

Pre-Update Assessment

Before making changes, assess:

Clarify the change request

  • Role change or project scope change? Determine if adjusting organization role, project list, or both
  • Permanent or temporary? Document planned revert date if temporary elevation
  • Which environments? List specific projects/environments (production, staging, QA) to add or remove
  • Module permissions needed? Identify if Govern, Illuminate, or Activate access is required
  • Reason for change: Business justification, security requirement, or organizational change

Review current state

  1. Go to Account → Manage → Members and locate the user
  2. Note current:
    • Organization role (Admin, Member)
    • Project assignments and roles for each environment
    • Module permissions (Govern, Activate, Illuminate)
    • Last activity date
  3. Screenshot for "before" record
  4. Document which events, funnels, or dashboards they currently manage

Identify impact of changes

If reducing permissions (downgrading role, removing projects):

  • Check if user owns events, funnels, segments, dashboards in projects being removed
  • Verify no active integrations depend on their access
  • Ensure another Admin exists for projects losing Admin access
  • Confirm data pipelines or webhooks won't break

If expanding permissions (upgrading role, adding projects):

  • Confirm business justification and approval
  • Verify user needs the elevated access for their job function
  • Document expected scope and duration
  • Set calendar reminder if temporary
  • Consider data privacy implications of broader access

Obtain approval

For role elevations, project additions, or module access grants:

  • User's manager or department head
  • Data governance lead if adding Govern access for tracking plan management
  • Security or compliance if adding Admin or organization-level rights
  • Product owner if adding access to specific product environments
  • Save approval for compliance audit trail

Change Execution

Step 1: Access user management

  1. Sign in as Admin or Organization Owner
  2. Go to Account → Manage → Members
  3. Locate the user by name or email
  4. Click on their name to open the user profile

Step 2: Adjust organization role (if needed)

If organizational responsibilities changed:

  1. In Organization Role section, select new role:
    • Admin: Full organization control (billing, user management, all projects)
    • Member: Standard user with project-level permissions only
  2. Consider impact:
    • Upgrading to Admin: User gains access to billing, user management, SSO configuration, all projects, and organization settings
    • Downgrading from Admin: Loses organization-level privileges; retains only explicit project permissions
  3. Save changes

Best practice: Use Organization Admin sparingly. Most users should be Members with project-level permissions.

Step 3: Modify project access (if needed)

If project scope changed:

  1. In Projects section, review current project list
  2. Adding projects:
    • Click + Add or check boxes for new projects
    • Select appropriate role for each project:
      • Admin: Full project control (settings, tracking plan, integrations, data management)
      • Member: Can create/edit analyses, funnels, and dashboards
      • Viewer: Read-only access to shared content
  3. Removing projects:
    • Uncheck boxes for projects to remove
    • Or delete the project assignment
  4. Changing project roles:
    • Update dropdown for each project individually
  5. Save changes

Best practice: Separate production, staging, and development projects. Grant production Admin access sparingly.

Step 4: Adjust module permissions (if needed)

If add-on module access changed:

  1. In Module Permissions section:
    • Govern: Tracking plan management, data quality rules, schema editor
    • Illuminate: Session replay and user journey analysis
    • Activate: Messaging, in-app guides, and user activation tools
  2. Enable or disable module access per project as needed
  3. For Govern specifically:
    • Tracking Plan Editor: Can approve/block events, define event schemas
    • Tracking Plan Viewer: Can view but not edit tracking plans
  4. Save changes

Step 5: Save and verify

  1. Click Save or Update
  2. Refresh and verify:
    • Organization role updated correctly
    • Project list shows correct additions/removals
    • Project roles reflect changes
    • Module permissions are accurate
  3. Screenshot for "after" record
  4. Check Activity Log to confirm change was recorded

Step 6: Notify the user

Send email or Slack message to user explaining:

  • What changed: New role, updated project list, module permissions added/removed
  • Why: Business justification or organizational change
  • When effective: Immediate (but may need browser refresh)
  • What they can now do: New capabilities or restrictions
  • Duration: If temporary, when access will be reverted
  • Contact: Who to ask if questions or issues

Post-Update Validation

User confirmation

  • Ask user to refresh Heap and verify expected project access
  • If upgraded to Admin, verify can access organization settings
  • If downgraded, verify cannot access previous Admin features
  • Check that new projects appear in project selector

Functional testing

Test specific changes:

  • Organization Admin: Can access billing, user management, organization settings
  • Project Admin: Can manage project settings, tracking plan, integrations, data retention
  • Member: Can create analyses, funnels, dashboards but not manage project settings
  • Viewer: Can only view shared content; cannot create new analyses
  • Govern access: Can edit tracking plan schemas and approve/block events
  • Illuminate access: Can view session replays and user journeys
  • Activate access: Can create in-app messages and user activation campaigns

Module verification

If changed module access:

  • Govern: Verify can access Tracking Plan editor and data quality dashboard
  • Illuminate: Check that session replay player loads correctly
  • Activate: Test that messaging and guides interface is accessible

Documentation

  • Update access log with details:
    • User email and name
    • Date of change
    • Organization role: old → new
    • Projects: added/removed with roles
    • Modules: granted/revoked
    • Reason and approver
    • Temporary or permanent
  • Update team roster or RACI matrix
  • Add note to ticketing system
  • Update documentation that lists user responsibilities

Monitoring

  • Set follow-up reminder for 1-2 weeks to verify working as expected
  • If temporary elevation, set calendar alert to revert on planned date
  • Include in next quarterly access review
  • Monitor activity logs for any unusual activity after permission increase

Bulk Update Operations

For updating multiple users at once:

Via SCIM/SSO

If using automated provisioning:

  1. Update user attributes in identity provider (Okta, Azure AD, etc.)
  2. Verify SCIM sync completes within expected timeframe (usually 15-30 minutes)
  3. Check Heap for updated roles and permissions
  4. Document which IdP groups map to which Heap roles/projects

Manual bulk updates

Heap doesn't have native bulk update UI:

  1. Document all users requiring the same change
  2. Process each user individually through user management
  3. Use consistent approach for each
  4. Screenshot each before/after
  5. Document all changes in single access review ticket

Troubleshooting

User can't see new projects:

  • Verify projects were saved correctly
  • Have user log out completely and back in
  • Check if SSO/SCIM is overriding manual changes
  • Confirm projects are active and not archived

User still has old role permissions:

  • Confirm save completed successfully
  • Have user clear cache and reload Heap
  • Check if SSO attributes are reverting the change
  • Contact Heap support if persists

User lost access to funnels they created:

  • If projects were removed, funnels in those projects become inaccessible
  • Re-add project access temporarily to export funnels
  • Or have another Admin with access export/transfer them

Upgraded to Admin but can't access billing:

  • Organization role must be set to Admin, not just project Admin
  • Verify change was saved at organization level
  • Some billing features may be Owner-only
  • Contact Heap support

Module permissions not working:

  • Verify organization has purchased the module
  • Confirm module is enabled for the specific project
  • Check if user needs both organization AND project-level module permission
  • Have user log out and back in
  • Contact Heap support to verify module licensing

SCIM keeps reverting manual changes:

  • SCIM provisioning will override manual role changes
  • Make changes in identity provider instead
  • Document SCIM role mapping for team reference
  • Or temporarily disable SCIM sync for manual override (not recommended)

Best Practices

  • Document every change with reason, approver, and date
  • Screenshot before and after for compliance audit trails
  • Notify users immediately after access changes
  • Set revert reminders for temporary elevations
  • Use least privilege: Grant minimum access needed (prefer Viewer/Member over Admin)
  • Review quarterly: Verify all users still need current access levels
  • Separate environments: Use different projects for production, staging, development
  • Test after changes: Verify user has expected permissions
  • Coordinate with data team: Align role changes with data governance policies
  • Maintain separation of duties: Avoid granting excessive Admin access

Common Use Cases

Promoting Product Analyst to Team Lead

  1. Obtain approval from department head
  2. Review current projects and identify gaps
  3. Upgrade organization role from Member to Admin (if needed for team management)
  4. Add projects they'll now manage
  5. Grant Govern access if they'll manage tracking plan quality
  6. Set project role to Admin for teams they'll lead
  7. Document promotion with effective date
  8. Notify user of new responsibilities and access

Downgrading departing Admin (pre-offboarding)

  1. Confirm departure timeline with HR
  2. Identify assets owned (events, funnels, dashboards, segments)
  3. Transfer ownership to replacement or manager
  4. Downgrade organization role from Admin to Member
  5. Reduce project roles to Viewer for final weeks (read-only access)
  6. Keep access active until official last day
  7. Document downgrade and planned full removal date

Temporarily elevating for integration setup

  1. Obtain approval with specific task and revert date
  2. Screenshot current access state
  3. Upgrade to project Admin for relevant project only
  4. Grant necessary permissions for integration configuration
  5. Notify user to complete task by specified date
  6. Set calendar reminder to revert on completion date
  7. After task complete, downgrade back to previous role
  8. Document temporary elevation in audit log

Expanding scope (agency wins new client)

  1. Confirm new client/product covered by contract/SOW
  2. Obtain approval from account owner or procurement
  3. Add new project(s) to user's access list
  4. Set appropriate role (usually Member or Admin)
  5. Verify user can access new projects
  6. Document with contract or SOW reference
  7. Notify agency of expanded access
  8. Update vendor access documentation

Reducing scope (product sunset)

  1. Confirm product/project is being deprecated or sunset
  2. Identify all users with access to the project
  3. Transfer any critical funnels, segments, or dashboards to other projects
  4. Remove project from user's access list
  5. Verify user no longer sees project in Heap
  6. Document project sunset and access removal
  7. Update team documentation
  8. Consider archiving project if supported

Moving user between product teams

  1. Confirm organizational change with HR or manager
  2. Review current project access and determine new needs
  3. Add projects for new product team
  4. Remove projects from old product team (unless overlap needed)
  5. Adjust roles to match new responsibilities
  6. Update organization role if team lead responsibilities change
  7. Transfer ownership of assets if applicable
  8. Document organizational change
  9. Notify both old and new managers
  10. Update team roster and org chart

Granting Govern access for data quality

  1. Confirm user will manage tracking plan schemas and data quality
  2. Obtain approval from data governance lead
  3. Enable Govern module access for relevant projects
  4. Set to Tracking Plan Editor if they'll approve/block events
  5. Set to Tracking Plan Viewer if read-only needed
  6. Train user on tracking plan workflows and data quality dashboard
  7. Document grant with governance approval reference
  8. Notify engineering team of new tracking plan owner

Granting Illuminate access for UX research

  1. UX researcher needs session replay access for user behavior analysis
  2. Obtain approval from product lead and legal (due to PII in replays)
  3. Grant Illuminate module access for relevant projects
  4. Set project role to Member (can view but not configure)
  5. Train on PII redaction settings and privacy considerations
  6. Document grant with legal approval reference
  7. Set reminder for periodic access review (replays contain sensitive data)

Seasonal contractor access adjustment

  1. Contractor returning for seasonal work (e.g., holiday analytics support)
  2. Review previous access and projects
  3. Re-enable projects for current season
  4. Set appropriate time-limited role (usually Viewer or Member)
  5. Document contract start and end dates
  6. Set calendar reminders for access removal at contract end
  7. Notify contractor of access grant
  8. Track in vendor management system

Compliance-driven access reduction

  1. Security audit identifies excessive Admin permissions
  2. Document current access levels across all projects
  3. Work with user's manager to determine minimum required access
  4. Downgrade from Admin to Member where appropriate
  5. Remove access to unnecessary projects (especially production)
  6. Revoke unused module permissions
  7. Screenshot before and after states
  8. Document compliance requirement driving change
  9. Report changes to security/compliance team
  10. Schedule follow-up review in 90 days
Nach oben