How to manage workspace access and costs with Myaza Trust
Manage team access, environments and cost controls deliberately. Give each teammate the permissions needed for their job and keep Sandbox preparation separate from Production activity.
Charles Archibong, Co-founder
· 3 min read
Key takeaways
- A reader cannot perform management actions.
- Environment switching shows the intended records and keys.
- Secret values are absent from client code and public images.
- A saved change survives reload and has audit evidence.
- Pricing uses the current organisation’s quoted components.
Manage team access, environments and cost controls deliberately. Give each teammate the permissions needed for their job and keep Sandbox preparation separate from Production activity.
Before you begin
Authorised organisation or billing access
Current workspace and environment
Use a team member with permission for this control. Check the organisation and environment before changing a setting. Review the current price before a paid check or ongoing enrolment. Screenshots show an example workspace or the public integration reference; they do not show a real customer or a completed paid check.
Set up and use the capability
Step 1: Check your organisation and environment
Use the dashboard workspace selector to confirm the organisation and environment before viewing data or changing settings. Sandbox and Production separate keys, workflows, results and receivers. A URL alone may not identify which environment you are viewing. Confirm the displayed state after switching, especially before editing a published control or a billing setting.
Integration reference: Switching environments in the dashboard
Step 2: Review the team’s actual permissions
Open the organisation’s Team settings and inspect the member and role you intend to manage. Separate readers from people who can publish workflows, manage rules, review evidence or change billing. Use the supported role controls and required confirmation. A visible page or shared organisation membership does not grant authority to every record or action.
Integration reference: Creating and managing keys
Step 3: Keep organisation security separate from personal settings
Use Organisation settings → Security for organisation-wide requirements and personal account security for the current user’s sign-in. Preserve the required two-factor confirmation before privileged changes. Give teammates a usable enrolment and recovery path. A local personal change cannot substitute for an organisation-wide policy, and a role change should not be used to bypass a missing security requirement.
Integration reference: Best practices
Step 4: Create credentials for the right service
Open Developers → API Keys in the intended environment. Choose Publishable for supported client capture and Secret for backend results or Risk Intelligence. Secret values are shown once: store them immediately in the backend secret manager. Use separate service credentials where appropriate so revocation does not disrupt every integration. Do not place secret keys in screenshots, source code or a mobile build.
Integration reference: Creating and managing keys
Step 5: Review current prices and balance
Open Billing → Rate card for the organisation’s current component pricing, then inspect balance and low-balance settings. Review a workflow’s per-check estimate and a batch or recurring operation’s actual quote before activation. Eligible Usage Credits apply to the components and remaining pool the service returns; do not divide or invent free allowances. A covered step can coexist with payable checks in the same journey.
Integration reference: Billing
Step 6: Verify changes and retain audit evidence
Reload the relevant setting or record after a permitted save and inspect the organisation’s Audit Logs for the action. Review user, environment and resource binding when troubleshooting an unexpected change. Keep key and webhook rotation evidence separate from product activation. Do not assume a saved team, billing or security setting proves that a customer-facing integration is fully live.
Integration reference: Best practices
Get more from the capability
Separate routine reader access from publication and investigation authority.
Review service keys and members periodically, revoking access through the supported process when it is no longer needed.
Review batch and recurring cost estimates before activation, then reconcile recorded usage rather than guessing from the number of visible rows.
Test before relying on it
Run the supported Sandbox or simulator scenarios for this product. Where a tool is Production only, check access and scope first, then use only a permitted, deliberately reviewed Production test. A documentation screenshot or a successful page load is not an end-to-end integration test.
A reader cannot perform management actions.
Environment switching shows the intended records and keys.
Secret values are absent from client code and public images.
A saved change survives reload and has audit evidence.
Pricing uses the current organisation’s quoted components.
Troubleshooting
A control is missing or disabled
Check role, product access, environment and security requirements before assuming the feature is broken.
A secret key cannot be shown again
It is intentionally shown once. Use the supported new-key and controlled replacement process.
The balance does not match my estimate
Inspect actual usage components, credits and recorded charges in the intended workspace.
Open the setup and integration references
Back to Solutions. Choose the capability you want to activate, then follow its own guide.
Sources
Charles Archibong
Co-founder
Charles Archibong co-founded Myaza Trust. He writes about identity verification, financial technology, and the practical work of building trusted digital services.
