Update User Access

Use this procedure to modify existing project sharing permissions when user responsibilities change or access scope needs adjustment.

Prerequisites

Before updating project access, verify:

• You are the project owner (only owners can modify sharing)
• You know which user's access needs modification
• You've determined the new permission level needed (Full Access or View Only)
• You've documented the business justification for the change
• The user has been informed of the pending permission change

Step-by-Step: Update Project Sharing Permissions

1. Access Project Sharing Settings

1. Log into StatCounter as the project owner
2. Go to your Projects list
3. Click on the project where sharing needs to be modified
4. Navigate to Project Settings → Sharing or Share Access

2. Document Current Configuration

Before making changes, capture the existing state:

1. Take screenshot of current sharing list showing user's permission level
2. Note the user's current permission (Full Access or View Only)
3. Record why the change is needed
4. Store this pre-change documentation

3. Modify User Permissions

1. Find the user in the project's sharing list
2. Click Edit or click on the user's current permission level
3. Select the new permission level from the options:
   • Full Access - User can view reports and modify project configuration
   • View Only - User can view reports but cannot modify settings

4. Save and Verify

1. Click Save or Update to apply the change
2. Verify the user now appears with the correct new permission level
3. Changes take effect immediately - user may need to refresh browser

5. Confirm with User

1. Notify the user their permissions have changed
2. Explain what they can now do (if upgraded) or no longer do (if downgraded)
3. Ask them to log out and back in to ensure changes are applied
4. Verify they see expected capabilities in the project

After Update: Documentation Steps

Record the change:

• Document: date, project name, user email, old permission, new permission, justification
• Add entry to your access change log
• Update project access mapping documentation

Verify dependent configurations:

• If downgrading from Full Access to View Only, ensure no critical configurations relied on this user
• For upgrades to Full Access, brief user on their new configuration capabilities
• Monitor for any unexpected changes after granting Full Access

Communicate stakeholders:

• Inform relevant stakeholders if this affects project support
• Update team documentation if responsibilities changed
• Provide training if user gained new Full Access capabilities

Common Update Scenarios

Upgrading from View Only to Full Access

Situation: User initially given read-only access now needs to configure tracking or modify project settings.

Process:

1. Verify business justification (promoted to technical role, new responsibilities, etc.)
2. Document the upgrade reason
3. Edit user in sharing settings and change to Full Access
4. Brief user on their new configuration capabilities and responsibilities
5. Monitor initial configuration changes to ensure proper use
6. Update access documentation to reflect elevated permission

Downgrading from Full Access to View Only

Situation: User's role changed and configuration access is no longer needed.

Process:

1. Document why downgrade is needed (role change, project phase completed, etc.)
2. Ensure any critical configurations created by this user are documented
3. Edit user in sharing settings and change to View Only
4. Verify user can still view reports but cannot access settings
5. Notify user they retain reporting access but configuration access is revoked
6. Update access documentation

Temporary Privilege Elevation

Situation: View Only user needs brief Full Access for a specific configuration task.

Process:

1. Document the specific task and expected duration
2. Upgrade to Full Access temporarily
3. Set calendar reminder to downgrade back to View Only
4. Monitor user's configuration activities during elevation
5. Downgrade immediately after task completes
6. Document the temporary elevation period

Multi-Project Permission Alignment

Situation: User has different permissions across multiple projects and you need to standardize.

Process:

1. Audit all projects shared with this user
2. Determine appropriate standard permission level
3. Update each project individually (StatCounter doesn't support bulk updates)
4. Verify consistent permissions across all projects
5. Document the standardization

Troubleshooting Update Issues

Permission Change Doesn't Take Effect

Symptoms: User reports they still have old permissions after update.

Solutions:

1. Verify change was saved (check sharing list shows new permission)
2. Have user log out completely and log back in
3. Clear browser cache or try incognito mode
4. Verify you updated the correct project and user
5. Contact StatCounter support if issue persists

User Lost All Access After Update

Symptoms: After modifying permissions, user cannot access project at all.

Solutions:

1. Verify user still appears in sharing list (ensure you didn't accidentally remove them)
2. If accidentally removed, re-share the project with appropriate permissions
3. Have user refresh browser or try logging in again
4. Check for typos in email address if you had to re-add

Cannot Modify Owner Permissions

Symptoms: Unable to change the project owner's access level.

Solutions:

1. Project owners cannot have their permissions modified through sharing settings
2. Owner always has full control of their own projects
3. To transfer ownership, use StatCounter's ownership transfer feature (separate from sharing)
4. If you need to restrict owner access, consider organizational policy rather than platform controls

Update Affects Other Shared Projects

Symptoms: Changing permissions in one project seems to affect others.

Solutions:

1. StatCounter manages sharing per-project - changes should only affect the specific project
2. Verify you're updating the correct project
3. Check that you haven't inadvertently updated multiple projects with same user
4. Each project's sharing is independent - update each one separately if needed

Best Practices for Permission Updates

Regular access reviews:

• Quarterly reviews of all project sharing to ensure permissions still match current needs
• Audit Full Access users to verify elevated permissions are still required
• Downgrade users who completed configuration work and now only need reporting access

Principle of least privilege:

• Start with View Only and upgrade only when configuration access is genuinely needed
• Downgrade back to View Only after configuration phases complete
• Question any Full Access permissions that seem unnecessary

Change management:

• Always document why permissions are changing
• Capture before and after states for audit trail
• Notify users before making changes when possible
• Follow up to verify changes worked as intended

Temporary elevations:

• Use time-limited Full Access upgrades for specific tasks
• Set reminders to downgrade after task completion
• Document temporary elevation periods clearly
• Consider whether a permanent Full Access user should perform the task instead

Communication:

• Inform users before changing their permissions
• Explain new capabilities (upgrades) or restrictions (downgrades)
• Provide training for users receiving Full Access
• Follow up to ensure users understand their updated permissions

Security Considerations

Upgrade justification:

• Require documented business need before elevating to Full Access
• Verify the requestor and user identity before granting elevated privileges
• Monitor configuration changes made by newly upgraded users

Regular downgrades:

• Review Full Access users quarterly and downgrade those who no longer need configuration access
• After major implementations or migrations, downgrade contractors back to View Only
• Challenge any Full Access permissions that seem to persist without clear ongoing need

Audit before changing:

• Document current state before modifying permissions
• Screenshot sharing configuration for compliance records
• Maintain change log showing permission history

Monitor elevated users:

• Watch for unexpected configuration changes after granting Full Access
• Verify new Full Access users understand project settings before making changes
• Have rollback plan if user makes problematic configuration changes

Compliance Documentation

For each permission update, document and retain:

• Change date and time: When permissions were modified
• Project name: Which project's sharing was updated
• User email: Email address affected
• Old permission level: Previous access level (Full Access or View Only)
• New permission level: Updated access level
• Business justification: Why change was needed
• Requestor: Who requested the change
• Approver: Who approved and implemented the change
• Verification: Confirmation that changes took effect

Store update records according to compliance retention requirements, typically 7 years for regulated industries. This documentation supports access control audits and demonstrates proper change management.