General Access Sharing Rules for Metricfixer Support

This guide explains the general access-sharing rules for working with Metricfixer. Use it before sending repository, hosting, CMS, analytics, advertising, database, or server access for a support ticket.

Core principle

Give Metricfixer only the access required to diagnose, repair, test, or deploy the specific task described in your ticket.

The preferred workflow is:

1. share the project context and required technical information;
2. give limited access to the repository, staging environment, or relevant platform;
3. let us prepare changes in a branch, pull request, workspace, duplicate theme, or staging environment;
4. review the result;
5. approve production changes only when needed;
6. revoke temporary access after the ticket is completed.

Before you share access

Please confirm that you are authorized to provide access to the website, repository, account, server, analytics property, advertising account, ecommerce platform, CRM, or other system involved in the ticket.

Before implementation work begins, prepare the following where applicable:

• the website or application URL;
• a short description of the problem and the expected result;
• repository URL and main production branch, if the project uses Git;
• staging URL, preview URL, or test environment details, if available;
• CMS, ecommerce, analytics, advertising, or hosting platform names;
• build, test, deploy, or cache-clear commands, if known;
• screenshots, logs, examples, or steps to reproduce the issue;
• confirmation that appropriate backups or exports exist before risky changes;
• the name or email of the person who can approve production changes.

Use staging whenever possible

Metricfixer prefers to diagnose and implement changes in a staging, preview, sandbox, duplicate theme, test workspace, or development environment before production is changed.

Production changes should usually happen only after one of the following:

• you review and approve the staging result;
• a pull request or change summary has been reviewed;
• a backup or rollback option exists where the change carries operational risk;
• the ticket is explicitly handled as an emergency production hotfix.

Safe ways to provide access

Use account invitations and limited user roles instead of sending shared passwords. Where possible, create a separate temporary user for Metricfixer.

Good access-sharing methods include:

• GitHub, GitLab, Bitbucket, Shopify, WordPress, Google, Meta, TikTok, hosting, or cloud account invitations;
• temporary users named in a recognizable way, such as metricfixer-support, metricfixer-deploy, or metricfixer-ticket-1234;
• repository permissions limited to the specific repository involved in the ticket;
• staging-only CMS, database, server, or deployment access where possible;
• read-only access for diagnostics when edit permissions are not yet required;
• time-limited tokens or credentials when an invitation-based method is not available;
• ticket-system secure fields or another method explicitly approved by Metricfixer for sensitive access details.

What access level should you choose?

The required access level depends on the task. Start with the lowest practical permission and increase it only if Metricfixer confirms that more access is necessary.

• Read-only: suitable for audits, diagnostics, reviewing settings, logs, reports, or configuration.
• Editor or developer: suitable when we need to change tags, themes, plugins, code, branches, settings, or platform configuration.
• Deploy or staging access: suitable when we need to publish changes to a staging environment or run a controlled deployment process.
• Production deployment access: used only when the agreed task requires it and the production change has been approved.
• Owner, root, full administrator, billing, or organization-level access: not required by default and should not be provided unless Metricfixer specifically explains why it is unavoidable.

What not to send by ordinary email or chat

Please do not send the following by ordinary email, chat, public links, screenshots, or unprotected documents:

• passwords;
• private keys;
• API secrets;
• authentication tokens;
• database root credentials;
• hosting master account credentials;
• production .env files;
• full payment card data;
• government identification data;
• health data, children’s data, or other sensitive personal data;
• large customer exports or production database dumps unless they are clearly required and have been minimized or sanitized where possible.

If you accidentally send a secret or sensitive file, tell us immediately. You may also need to rotate the affected password, token, key, or credential.

Access we normally do not need

For most support tickets, Metricfixer does not need:

• GitHub organization owner access;
• repository admin access when write access is enough;
• cloud account owner or root access;
• hosting provider billing access;
• domain registrar owner access unless the task is specifically about DNS or domain configuration;
• payment provider live secret keys unless the task explicitly requires payment integration work;
• production database write access unless the agreed task requires a controlled database change;
• personal employee accounts that are not intended for external support use.

Production access and approvals

Production access should be treated as a higher-risk permission. If a task requires production changes, Metricfixer may ask for a written approval in the ticket before the change is made.

Depending on the risk level, we may also ask for:

• confirmation that a backup or export exists;
• a maintenance window;
• a rollback plan;
• a list of files, settings, database changes, or platform settings affected by the change;
• confirmation of who is authorized to approve the deployment.

If your security policy does not allow external access

If you cannot give Metricfixer direct access, we can often work in a client-executed mode. In this mode, you provide redacted screenshots, logs, exports, configuration examples, or repository snapshots, and we provide patches, instructions, or review comments for your team to apply.

This method can be safer for restricted environments, but it may require more back-and-forth and may increase the time needed to diagnose or verify the issue.

After the ticket is completed

After the agreed work is completed, please review and revoke access that is no longer needed.

1. Remove temporary Metricfixer users from GitHub, CMS, hosting, analytics, advertising, ecommerce, cloud, or other platforms.
2. Remove temporary deploy keys, access tokens, API keys, and service credentials that are no longer required.
3. Rotate any password, token, or key that was shared outside an invitation-based access system.
4. Confirm that production secrets were not added to a repository, public document, ticket message, or email thread.
5. Keep any agreed permanent access only if it is part of an active support arrangement.

Quick checklist

• I am authorized to provide access for this project.
• I have shared only the access required for the ticket.
• I used a temporary or role-based account where possible.
• I avoided sending passwords, private keys, API secrets, tokens, or full production secrets by email.
• I confirmed whether staging, preview, sandbox, or duplicate-theme testing is available.
• I confirmed that backups or exports exist before risky production changes.
• I know who can approve production deployment.
• I will revoke or reduce access after the ticket is completed.