Update Chartbeat Roles for the collaborator | OpsBlu Docs

Update Chartbeat Roles for the collaborator

How to modify user roles, permissions, and access levels in Chartbeat. Covers role changes, app access management, API key rotation, and common access.

Modify the collaborator's Chartbeat permissions when engagement scope evolves, security policy changes, or new sites are added to the account. Regular access reviews ensure users maintain appropriate privilege levels aligned with current business needs.

Understanding Access Updates

Chartbeat permissions can be modified at multiple levels:

Role Changes

Switching between Administrator and User roles affects account-wide capabilities:

  • Elevating to Administrator grants configuration rights, user management, and API access
  • Downgrading to User restricts access to read-only dashboard viewing
  • Role changes take effect immediately upon saving

Site Permission Changes

Adjusting site or site group assignments controls which properties a user can view:

  • Add sites when new properties launch or scope expands
  • Remove sites when engagement focus narrows or contracts end
  • Site group membership simplifies bulk permission management
  • Changes appear after the user's next login or page refresh

Authentication Method Changes

SSO or MFA policy updates may require account reconfiguration:

Situations Requiring Updates

Common scenarios that trigger permission modifications include:

Scope Expansion

  • New site launches: The collaborator needs access to recently added properties for implementation QA or ongoing monitoring.
  • Multi-brand rollouts: Additional site groups must be assigned as the client expands Chartbeat to new divisions or markets.
  • Implementation support: The engagement shifts from reporting-only to configuration work, requiring Administrator elevation.
  • Staging environment access: Development properties need to be included for pre-production testing.

Scope Reduction

  • Contract changes: The statement of work narrows to specific sites, requiring removal of out-of-scope properties.
  • Transition to maintenance: Active implementation completes, and the collaborator should downgrade to User role for ongoing reporting.
  • Offboarding preparation: Gradual access reduction as engagement winds down, removing all but essential sites.

Security and Compliance

  • MFA enforcement: Organization policy now requires multi-factor authentication for all external users.
  • SSO migration: Accounts are transitioning from username/password to SAML-based single sign-on.
  • Access review findings: Quarterly audits identify unnecessary privileges that should be revoked.
  • Password rotation: Security policy requires credentials be updated on a fixed schedule.

Organizational Changes

  • Site group restructuring: Your Chartbeat account reorganizes site groups, requiring user reassignment.
  • Account mergers: Multiple Chartbeat instances consolidate, necessitating permission realignment.
  • Team role changes: The collaborator's responsibilities shift within their organization.

Update Workflow

Follow this step-by-step process to modify permissions:

1. Prepare for the Change

  • Verify you have the authorization to make the change (approval email, ticket number, SOW reference).
  • Confirm you have Account Administrator rights in Chartbeat.
  • Review the current state of the user's permissions in Settings → Users.
  • Document the reason for the change and expected new access levels.

2. Navigate to User Management

  • Log into Chartbeat with administrator credentials.
  • Go to Settings → Users from the main navigation.
  • Locate the collaborator's account in the user list.
  • Click the user's name or the Edit button to open their profile.

3. Modify Permissions

Adjust the appropriate settings based on your change requirements:

To change the role:

  • Select the new Role from the dropdown (Administrator or User).
  • Review the role description to confirm it matches the intended permission level.

To update site access:

  • Scroll to the Sites or Site Groups section.
  • Check boxes to add new sites or site groups.
  • Uncheck boxes to remove access to specific properties.
  • Use Select All / Deselect All for bulk changes when appropriate.
  • Verify staging/production environments are correctly configured.

To add custom notes:

  • Enter the ticket number, request date, or business justification in the Notes field.
  • Include the approver's name for audit trail purposes.

4. Save and Communicate

  • Click Save Changes at the bottom of the form.
  • Verify the success message appears confirming the update.
  • Notify the collaborator's engagement lead via email:
    • Summarize what changed (role, sites added/removed).
    • Explain the business reason for the update.
    • Provide a timeline for when changes take effect (immediate).
    • Include any action items (e.g., "please log out and back in to see new sites").

5. Verify the Change

  • Return to Settings → Users and open the collaborator's profile again.
  • Confirm all changes are reflected correctly.
  • Ask the collaborator to log in and validate they see the expected sites.
  • Check that the user can (or cannot) access restricted features based on their new role.

Validation Checklist

After making changes, complete these verification steps:

System Validation

  • User record in Settings → Users displays the updated role.
  • Site assignments match the approved change request.
  • Notes field contains the ticket or approval reference.
  • Change timestamp shows the current date and your admin username.

User Validation

  • Collaborator confirms they can log into Chartbeat successfully.
  • Dashboard selector shows correct sites (and only approved sites).
  • Real-Time and Historical dashboards load without errors.
  • Administrator features (Settings, User Management) are accessible or hidden based on new role.
  • API access (if applicable) works with updated permissions.

Documentation Validation

  • Screenshot or export captured showing updated permissions.
  • Access tracker or ITSM record updated with change details.
  • Approval email or ticket archived with change documentation.
  • Quarterly access review schedule updated if necessary.

API and Integration Updates

If the user's role or site access changed, review these integrations:

API Token Management:

  • If the user role was downgraded, rotate any API tokens associated with their account.
  • Administrator-to-User downgrades may invalidate API access for write operations.
  • Regenerate tokens and share new credentials securely via password manager or encrypted email.

Webhook and Alert Configuration:

  • Update Slack integrations if the user was added or removed as an alert recipient.
  • Modify email distribution lists for scheduled reports or threshold alerts.
  • Verify third-party integrations (Zapier, custom dashboards) still function correctly.

Data Export Permissions:

  • Confirm CSV export capabilities align with the new role.
  • Check if the user requires Historical API access for data warehouse workflows.

SSO and Authentication

For accounts using single sign-on:

  • Update IdP group memberships to mirror the Chartbeat role change.
  • If the user was switched from SSO to local authentication (or vice versa), provide new login instructions.
  • Verify SAML attribute mappings propagate the role change on next login.
  • Test SSO login flow to ensure no errors occur due to permission mismatches.

Site Group Management

If site groups were restructured:

  • Communicate the new site group names and purposes to the collaborator.
  • Update any documentation referencing old group names.
  • Consider creating a "transition period" where users have access to both old and new groups.

Compliance and Audit

Maintain proper records of all permission changes:

  • Log the modification in your IAM tracker with these fields:
    • Date of change
    • Requestor name and contact info
    • Approver name
    • Ticket or reference number
    • Old permissions (role and sites)
    • New permissions (role and sites)
    • Business justification
  • Retain before/after screenshots for compliance audits.
  • Update your access review schedule if the change affects review frequency.
  • If downgrading access in preparation for offboarding, set a final removal reminder.

Communication Best Practices

When notifying the collaborator about access changes:

  • Send a summary email within 24 hours of making the change.
  • Explain the business reason in neutral terms (avoid implying distrust).
  • Provide specific instructions: "You now have access to 5 sites instead of 12."
  • Include a contact for questions: "Reply to this email if you believe this is incorrect."
  • For significant downgrades, offer a brief call to explain context and answer questions.

Common Update Scenarios

Scenario 1: Adding Staging Site Access

The collaborator is beginning implementation QA and needs access to staging properties:

  • Keep role as Administrator (required for configuration testing).
  • Add staging site group or individual staging sites.
  • Ensure staging sites use different naming convention (e.g., "staging-example.com").
  • Remind the collaborator that staging data may not be production-quality.

Scenario 2: Downgrading After Implementation

Implementation completes and the collaborator transitions to reporting-only:

  • Change role from Administrator to User.
  • Keep site access the same (or reduce if only production monitoring is needed).
  • Rotate API tokens if the account previously used them.
  • Remove from notification lists for configuration alerts.

Scenario 3: Quarterly Access Review Cleanup

Your audit identifies sites the collaborator no longer needs:

  • Keep role unchanged.
  • Remove unchecked or out-of-scope site groups.
  • Send email explaining the access review process.
  • Document findings in your access tracker for the next review cycle.

Scenario 4: SSO Policy Enforcement

Your organization mandates SSO for all external users:

  • Work with your IdP team to create the user in the appropriate group.
  • In Chartbeat, associate the email with SSO authentication.
  • Test the login flow before notifying the user.
  • Provide updated login instructions (e.g., "use your company SSO portal").