How to manage reviewed lists with Myaza Trust
Use organisation lists to apply reviewed evidence consistently. Keep the decision to add an entry separate from the rules that decide what a list match does.
Charles Archibong, Co-founder
· 3 min read
Key takeaways
- A manager can save an authorised entry with a reason.
- Read-only members cannot mutate the list.
- The intended published rule handles a match.
- Historical decisions retain their original explanation.
Use organisation lists to apply reviewed evidence consistently. Keep the decision to add an entry separate from the rules that decide what a list match does.
Before you begin
Authorised list-management permissions
A documented review reason and workflow policy
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: Open your organisation’s Lists
Select the intended organisation and environment, then open Configuration → Lists. Choose the relevant list type from the available catalogue. Use face lists for face evidence and the appropriate document, user, device or contact list for that type of evidence. A team member with read access may be able to inspect entries without being allowed to change them.
Dashboard example: Open your organisation’s Lists
Step 2: Choose the intended list and review purpose
In Configuration → Lists, choose Face blocklist or Face allowlist. The catalogue explains what each list does: the blocklist declines a matching face, while the allowlist skips duplicate-face rules for a matching face. Open the intended list and review existing entries before adding another. Keep a documented purpose for the exception; an allowlist entry is not universal identity approval.
Dashboard example: Choose the intended list and review purpose
Step 3: Add a supported entry with a reason
For a face blocklist entry, select Add face. Upload one clear, front-facing photo in JPEG, PNG or WebP, up to 5 MB. Fill Name or reference (optional) with the reviewed case reference and Comment (optional) with why the face belongs here. Select Add to blocklist only after checking the intended organisation and source evidence. Other list types have their own fields; use their catalogue action rather than this face form.
Dashboard example: Add a supported entry with a reason
Step 4: Connect list findings to workflow rules
Open the workflow that should use the evidence and inspect the relevant Rules or decision graph. For face matches, enable Face search and review the offered list and duplicate handling. Test the configured action and its rule order. Adding an entry by itself is not proof that every workflow or transaction will block it.
Dashboard example: Connect list findings to workflow rules
Step 5: Save and publish the workflow
Wait for Saved in the editor. Select Publish, or Publish changes for an existing workflow. In the publication review, check the target environment, workflow ID, price and readiness warnings. Resolve blocking issues, then confirm Publish version. A saved draft is not the version customers use. New sessions use the new published snapshot; sessions already created retain their original version.
Dashboard example: Save and publish the workflow
Step 6: Review entries and outcomes over time
After testing a permitted fixture, inspect the verification or activity result to confirm the expected finding and decision. Keep the review rationale and list access limited to authorised managers. When an entry is no longer justified, use the supported management action and retain the relevant review history. Do not rewrite past verification or decision evidence to make it match the current list.
Integration reference: Audit
Get more from the capability
Use the list type that matches the evidence so a phone finding cannot be mistaken for identity proof.
Review stale entries periodically and keep a reason for additions and changes.
Test a listed and unlisted subject plus an unavailable-check path. A lookup failure cannot become an automatic allowlist match.
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 manager can save an authorised entry with a reason.
Read-only members cannot mutate the list.
The intended published rule handles a match.
Historical decisions retain their original explanation.
Troubleshooting
The add action is missing
Ask for the list-management permission appropriate to your role.
A saved entry had no effect
Check the exact list, environment, published workflow and rules using that type of finding.
A match looks incorrect
Inspect source evidence and record review. Do not compensate by changing unrelated customer records.
Open the setup and integration references
Read the integration reference
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.
