Update User Access in Hotjar | OpsBlu Docs

Update User Access in Hotjar

How to change user roles, modify permissions, and update team member access in Hotjar.

Overview

As team members change roles, projects evolve, or organizational needs shift, you may need to update user access in Hotjar. This includes:

  • Changing a user's role (upgrading or downgrading permissions)
  • Moving users between organization and site-level access
  • Adjusting access to specific sites

This guide explains how to update user access safely and effectively.

Prerequisites

To update user access, you must have:

  • Organization Owner or Admin role (to update org-level users)
  • Site Admin role (to update site-level users)

You cannot update access for users with higher privileges than yourself.

When to Update Access

Common Scenarios

Role Change:

  • UX Designer promoted to Product Lead → Upgrade from User to Admin
  • Contractor transitioning to full-time → Change from Viewer to User

Project Changes:

  • User moving to a different product team → Change site access
  • User needs temporary elevated access → Upgrade temporarily, then downgrade

Access Expansion:

  • Analyst needs access to additional sites → Grant site-level access
  • Stakeholder needs organization-wide visibility → Upgrade to org-level Viewer

Access Reduction:

  • Team member changed roles → Downgrade from Admin to User
  • External consultant project ending → Downgrade from User to Viewer

Security/Compliance:

  • Audit identifies over-privileged users → Downgrade to appropriate role
  • Policy change requires stricter access controls → Adjust multiple users

Updating Organization-Level User Roles

Step 1: Navigate to Organization Settings

  1. Log in to Hotjar
  2. Click your profile icon (top right)
  3. Select Organization settings
  4. Go to the Team tab

Step 2: Find the User

  1. Scroll through the user list or use the search box
  2. Locate the user you want to update

Step 3: Change Role

  1. Click the role dropdown next to the user's name
  2. Select the new role:
    • Admin: Full org access, can manage team
    • User: Can create/view insights across all sites
  3. The change is applied immediately

Step 4: Notify the User

  1. Send a message explaining the change
  2. Clarify what their new permissions include
  3. Answer any questions about access

Example message:

Hi [Name], I've updated your Hotjar access to Admin. You can now manage team members and site settings across all our properties. Let me know if you have any questions!

Updating Site-Level User Roles

Step 1: Navigate to Site Settings

  1. Log in to Hotjar
  2. Click Sites & Organizations (top navigation)
  3. Select the site where you want to update access
  4. Click Settings (gear icon)
  5. Go to the Team tab

Step 2: Find the User

  1. Scroll through or search for the user
  2. Locate the user you want to update

Step 3: Change Role

  1. Click the role dropdown next to the user's name
  2. Select the new role:
    • Admin: Full control over this site
    • User: Can create/view insights
    • Viewer: Read-only access
  3. Change is applied immediately

Step 4: Notify the User

Inform the user of the change and what it means for their day-to-day work.

Changing Access Level (Organization ↔ Site)

Moving User from Site-Level to Organization-Level

Scenario: User currently has access to one site but needs access to all sites.

Steps:

  1. Add organization-level access:

    • Go to Organization settings > Team
    • Invite user with desired org role
    • User receives email to accept (even if already in system)

  2. Remove site-level access (optional):

    • Go to each site's settings > Team
    • Remove user from site-level access
    • Not strictly necessary, but keeps permissions clean

Result: User has org-wide access instead of site-specific.

Moving User from Organization-Level to Site-Level

Scenario: User currently has org-wide access but should only access specific sites.

Steps:

  1. Add site-level access:

    • Go to desired Site settings > Team
    • Invite user with appropriate site role

  2. Remove organization-level access:

    • Go to Organization settings > Team
    • Click Remove next to the user
    • Confirm removal

Result: User retains access to specific sites but loses org-wide visibility.

Note: Be careful with this transition. User will lose access to all sites except those you explicitly grant.

Bulk Access Updates

For large teams, you may need to update multiple users at once.

Manual Bulk Update Process

  1. Create a spreadsheet documenting:

    • User name
    • Current role
    • Desired role
    • Reason for change

  2. Prioritize changes:

    • Security-related changes (downgrading over-privileged users)
    • Role changes due to departures
    • Upgrades for promotions

  3. Update systematically:

    • Start with organization-level changes
    • Then update site-level access
    • Track completion in spreadsheet

  4. Notify users:

    • Send a single communication explaining changes
    • Provide a contact for questions

Enterprise Automation (Contact Hotjar)

Enterprise plans may support:

  • CSV upload for bulk role changes
  • SSO/SAML integration with automated provisioning
  • API-based access management

Contact Hotjar support to explore options for your plan.

Best Practices for Updating Access

Do:

Follow principle of least privilege

  • Grant only the access needed
  • When in doubt, start lower and upgrade if needed

Document why access changed

  • Keep notes on why roles were updated
  • Useful for audits and future decisions

Review access regularly

  • Quarterly review of all user roles
  • Ensure roles still align with responsibilities

Communicate changes

  • Let users know when their access changes
  • Explain why and what they can now do

Test after changes

  • Ask user to confirm they can (or can't) perform expected actions
  • Verify changes took effect as intended

Don't:

Upgrade everyone to Admin "just in case"

  • Admin access should be limited
  • Leads to security and compliance risks

Forget to downgrade temporary access

  • Set reminders to revert elevated permissions
  • Temporary Admin should return to User/Viewer

Change access without notification

  • Surprising users with lost access causes frustration
  • Always communicate changes proactively

Make changes in production during critical periods

  • Avoid role changes during launches or peak analysis times
  • Plan updates during quieter periods

Update roles without understanding implications

  • Know what each role can and can't do
  • Test in a non-critical site if unsure

Common Update Scenarios

Scenario 1: Promoting a Team Member

Situation: UX Designer promoted to Product Lead, needs Admin access

Steps:

  1. Navigate to Site settings > Team
  2. Find designer's account
  3. Change role from User to Admin
  4. Send congratulatory message explaining new permissions
  5. Share documentation on admin responsibilities

Result: New Product Lead can manage site and team.

Scenario 2: Contractor Becoming Full-Time

Situation: Contractor had Viewer access, now joining team as full-time UX Researcher

Steps:

  1. Navigate to Site settings > Team
  2. Change role from Viewer to User
  3. If needed, grant organization-level access
  4. Send onboarding materials for internal team

Result: New team member can create surveys and analyze recordings.

Scenario 3: Reducing Access After Project Completion

Situation: External consultant had User access for a project, project now complete

Steps:

  1. Navigate to Site settings > Team
  2. Change role from User to Viewer (if ongoing observation needed)
  3. OR remove entirely if no longer needed (see Remove Access)
  4. Notify consultant of access change
  5. Thank them for their work

Result: Consultant retains visibility but can't modify anything.

Scenario 4: Security Audit Findings

Situation: Quarterly audit reveals 5 users have Admin access but only need User

Steps:

  1. Review each user's actual responsibilities
  2. Confirm with team leads which users truly need Admin
  3. Downgrade unnecessary Admins to User
  4. Document reason for each change
  5. Notify affected users with explanation

Result: Improved security posture, reduced risk.

Scenario 5: Expanding Access for Cross-Team Collaboration

Situation: Marketing Analyst needs access to Product site for cross-functional project

Steps:

  1. Navigate to Product site settings > Team
  2. Invite analyst (if not already in org)
  3. Grant User or Viewer role depending on needs
  4. Set calendar reminder to review access in 3 months
  5. Notify analyst and product team

Result: Analyst can collaborate while access is tracked for later review.

Updating Access for Multiple Sites

If a user needs updated access across multiple sites:

Option 1: Update Each Site Individually

Steps:

  1. Navigate to each site's settings > Team
  2. Update role for the user
  3. Repeat for all relevant sites

Use when: Updating 2-3 sites

Option 2: Grant Organization-Level Access

Steps:

  1. Invite user to organization with appropriate role
  2. Remove from individual sites (if desired)

Use when: User needs consistent access across many or all sites

Option 3: Remove and Re-Invite

Steps:

  1. Remove user from current access
  2. Re-invite with new role at org or site level

Use when: Significantly restructuring access

Verifying Access Changes

After updating access, verify changes took effect:

Ask the User to Confirm

  1. Request user log out and log back in
  2. Ask them to navigate to a site/feature
  3. Confirm they can (or can't) perform expected actions

Check Settings

  1. Navigate to Team settings where change was made
  2. Verify user's role displays correctly
  3. Check user's access on other sites if applicable

Test Permissions

  1. Ask user to attempt an action that requires their new role
  2. Example: If upgraded to Admin, can they invite a test user?
  3. Example: If downgraded to Viewer, can they still create surveys? (should fail)

Troubleshooting

Role Change Didn't Take Effect

Possible Causes:

  • User hasn't logged out and back in
  • Browser cache showing old state
  • Permissions not synced (rare)

Solutions:

  1. Ask user to log out and log back in
  2. Clear browser cache
  3. Try a different browser
  4. Wait a few minutes for sync
  5. Revert and reapply the change

User Still Can't Access Feature

Possible Causes:

  • Role doesn't include that permission
  • Plan doesn't support the feature
  • User looking at wrong site

Solutions:

  1. Verify role includes needed permission (see Role Matrix)
  2. Check if feature is available on your plan
  3. Confirm user is on the correct site
  4. Review Hotjar feature documentation

Can't Change a User's Role

Possible Causes:

  • You don't have permission to update that user
  • User has higher privileges than you
  • User is an Organization Owner (can't be changed by Admins)

Solutions:

  1. Verify you have Admin or Owner role
  2. Ask an Owner to make the change
  3. Confirm you're trying to update the correct user

Changes Not Appearing in Logs

Possible Causes:

  • Logs not refreshed
  • Change made at different level (org vs site)

Solutions:

  1. Refresh the page
  2. Check both organization and site team settings
  3. Wait a few minutes for logs to update

Audit Trail & Compliance

Tracking Access Changes

Hotjar maintains an audit trail of access changes:

  1. Go to Organization settings > Activity Log
  2. View history of:
    • Users added
    • Roles changed
    • Users removed
  3. Filter by date range or user
  4. Export for compliance documentation (if available on your plan)

Compliance Considerations

GDPR/CCPA:

  • Reducing access is as important as adding it
  • Document business justification for all Admin roles
  • Review access quarterly and document findings

Internal Policies:

  • Align role changes with company access policies
  • Require approval for Admin role grants
  • Maintain internal log of access changes with reasons

Security Reminders

Regular Access Reviews:

  • Review all user roles quarterly
  • Downgrade users who no longer need elevated access
  • Remove users who left the organization

Principle of Least Privilege:

  • Always grant the minimum access necessary
  • Upgrade only when clearly justified
  • Downgrade when responsibilities change

Communication is Key:

  • Never surprise users with access changes
  • Explain the reason for changes
  • Provide a contact for questions

Next Steps:

Additional Resources:

शीर्ष पर वापस जाएँ