Update User Access | OpsBlu Docs

Update User Access

Update user roles and permissions in Umami — modify access levels, change assignments, and audit changes.

Use this procedure to modify existing user accounts when responsibilities change, roles need adjustment, or website access requires updating.

Prerequisites

  • You have Admin role permissions (only Admins can modify users)
  • You've determined what needs to change (role, password, or website access)
  • You've documented the business justification for the modification
  • User has been informed of pending changes

Step-by-Step: Update User Account

1. Access User Management

  1. Log into Umami as Admin
  2. Navigate to SettingsUsers
  3. Locate the user to modify

2. Document Current State

Before making changes:

  1. Screenshot current user configuration
  2. Note current role and website access
  3. Record why change is needed
  4. Store in access control documentation

3. Edit User Account

  1. Click Edit or user's name
  2. User edit form appears with current settings

To change role:

  • Select Admin (full system access) or User (limited to assigned websites)
  • Understand implications: upgrading to Admin grants unrestricted access, downgrading to User requires assigning specific websites

To change password:

  • Enter new password (useful for password resets or rotation)
  • Share new password securely with user
  • Instruct user to change it again on next login

To modify website access (User role only):

  • Check/uncheck boxes for websites user should access
  • Admins automatically see all websites - cannot restrict
  • To restrict website access for an Admin, first downgrade to User role

4. Save Changes

  1. Review all modifications
  2. Click Save or Update
  3. Changes take effect immediately
  4. User may need to log out and back in to see updates

5. Verify and Communicate

  1. Verify changes saved correctly in users list
  2. Notify user of the modification
  3. Explain new capabilities or restrictions
  4. For role changes, provide orientation on new responsibilities

Common Update Scenarios

Promote User to Admin

Situation: User demonstrates need for system administration capabilities.

Process:

  1. Verify business justification for Admin access
  2. Document the promotion reason
  3. Edit user and change role to Admin
  4. Brief user on Admin responsibilities (user management, website creation)
  5. Monitor initial Admin activities
  6. User now sees all websites automatically

Downgrade Admin to User

Situation: Admin role no longer needed, user should have limited access.

Process:

  1. Document downgrade justification
  2. Identify which websites user still needs
  3. Edit user, change role to User
  4. Assign specific websites
  5. Save and verify user can access selected websites only
  6. Notify user of change

Add Website Access for User

Situation: User's responsibilities expanded to include additional websites.

Process:

  1. Edit user account
  2. Check boxes for additional websites
  3. Save changes
  4. Verify user sees new websites in their dashboard
  5. Notify user which websites they can now access

Remove Website Access for User

Situation: Project completed, user no longer needs access to specific websites.

Process:

  1. Edit user account
  2. Uncheck boxes for websites to remove
  3. Save changes
  4. Verify user no longer sees removed websites
  5. Export any final reports user may need before removing access

Reset Password

Situation: User forgot password or password needs rotation.

Process:

  1. Edit user account
  2. Enter new strong password
  3. Save changes
  4. Share new password securely with user
  5. Instruct user to change password immediately after login

Temporary Admin Elevation

Situation: User needs brief Admin access for specific task.

Process:

  1. Document task and expected duration
  2. Upgrade to Admin temporarily
  3. Set calendar reminder to downgrade
  4. Monitor activities during elevation
  5. Downgrade back to User immediately after task completes
  6. Reassign website access

Troubleshooting Update Issues

Changes Don't Take Effect

Symptoms: User reports seeing old permissions after update.

Solutions:

  1. Verify changes saved (check users list)
  2. Have user log out completely and log back in
  3. Clear browser cache
  4. Verify you edited correct user
  5. Check Umami server logs for errors

User Lost All Access After Downgrade

Symptoms: After changing Admin to User, user sees no websites.

Solutions:

  1. Verify you assigned at least one website when downgrading
  2. Users with zero websites have no access
  3. Edit user and assign appropriate websites
  4. User must have at least one website to see any data

Cannot Change Own Role

Symptoms: Cannot modify your own account while logged in.

Solutions:

  1. This is expected - prevents accidental self-lockout
  2. Use a different Admin account to modify your account
  3. If you're the only Admin, create second Admin first, then modify your account with the new Admin

Best Practices

Regular reviews:

  • Quarterly review of all user permissions
  • Verify roles still match responsibilities
  • Identify and downgrade unnecessary Admin accounts

Principle of least privilege:

  • Default to User role
  • Upgrade to Admin only when system management genuinely needed
  • Limit website access to minimum required

Change management:

  • Document all modifications
  • Capture before/after states
  • Notify users before making changes
  • Follow up to verify changes worked

Password management:

  • Rotate service account passwords annually
  • Reset passwords when users with knowledge depart
  • Use strong passwords (Umami has minimal requirements)

Security Considerations

Role changes:

  • Justify all Admin promotions with documented business need
  • Monitor newly promoted Admins closely
  • Regularly review and downgrade Admins who no longer need elevated access

Website access:

  • Review quarterly to ensure users still need assigned websites
  • Remove access to completed projects promptly
  • For multi-client scenarios, strict scoping prevents data leaks

Audit trail:

  • Document every permission change
  • Screenshot before/after configurations
  • Maintain change history for compliance

Compliance Documentation

For each user modification, document:

  • Change date and time
  • Username modified
  • Old configuration (role, websites)
  • New configuration (role, websites)
  • Business justification
  • Requestor
  • Approver (Admin who made change)
  • Verification

Store modification records for compliance retention period (typically 7 years for regulated industries).