Changing a verification flow without shipping an app release
Mount the SDK with a workflow ID and the flow's configuration is fetched from the server on each verification. Re-publishing changes the steps, checks, copy and decision rules for the next verification, with no app release.
Charles Archibong, Co-founder
· 5 min read
Key takeaways
- With a workflow ID, the SDK fetches the published configuration, so a re-publish changes the flow with no redeploy.
- The workflow's settings win over overlapping props; per-user data and callbacks always stay in code.
- New SDK capabilities, native permissions and callback logic still need a release.
- Each verification records the workflow ID and version that ran, so every change stays attributable.
Mount the verification SDK with a workflow ID instead of spelling the flow out in code, and the flow's configuration comes from the server each time a verification starts. When you re-publish the workflow in the dashboard, the next verification in every installed copy of your app runs the new version. No build, no store review, no forced update.
That is what makes it practical to tighten a face-match threshold on a Tuesday afternoon, or add a proof-of-address step for one market, without a mobile release cycle. It does not remove releases entirely, and knowing the boundary is what keeps the approach safe.
How the SDK gets its configuration
A prop-configured mount carries the flow in your code: country, ID types, which steps run, branding, copy. Changing any of it means changing code, and on mobile that means an app-store round trip followed by weeks of users on old versions.
A workflow mount carries one identifier. The SDK sends it to the server when it mounts:
GET /api/kyc/workflows/:workflowId
Authorization: Bearer pk_…The response contains the published configuration, the ID types enabled for your organisation and the branding, and the SDK builds the flow from that. According to the workflows documentation, the workflow must belong to the API key's organisation and environment and be published; anything else returns an indistinguishable 404 workflow_not_found, and the SDK reports it through onError rather than silently running a different flow.
In a React Native app, the whole integration is:
import { MyazaKYC } from "@myazahq/kyc-sdk-react-native";
<MyazaKYC
apiKey="pk_live_…"
workflowId="wf_AbC123dEf456"
userId="user_42"
userData={{ firstName: "Jane", lastName: "Doe" }}
metadata={{ requestId: "order_1001" }}
onSubmit={(submission) => console.log(submission.verificationId)}
onError={(err) => console.error(err.code, err.message)}
>
Verify Identity
</MyazaKYC>The workflow's settings win over any overlapping props. If you pass a country and the workflow sets one, the workflow's value is used.
What you can change by re-publishing
Everything that describes the flow rather than the person:
Countries, ID types and the validation rules for each ID.
Capture steps and add-ons: contact codes, proof of address, the NFC chip step, questionnaires, address capture, multiple IDs in one run.
The liveness method (gestures, the screen-flash sequence, or both).
Branding, consent copy and success copy.
Policies such as age limits and how identity details that do not match are treated.
The decision graph: which results approve, which go to review, which decline.
A hypothetical example of the kind of change this makes routine: a lender sees a run of selfie mismatches caused by poor lighting and wants them in review rather than declined. They add a rule in the builder, check it in sandbox and re-publish. Every app version in the field applies the new rule from the next verification.
What still needs a release
Five things live in your code or your binary, and no amount of re-publishing moves them.
Per-user data. userId, userData and metadata are runtime values. A workflow is a template shared by everyone who runs it, so it cannot carry them.
Callbacks and what your app does with results. How you handle onSubmit, onError and the webhook on your backend is your code.
SDK versions. A workflow can only use capabilities the installed SDK understands. The documented minimums for workflowId are 2.2.0 for the web SDK, 2.1.0 for React Native and 2.2.0 for Flutter. Earlier web and React Native versions ignore the ID and run on props alone, which is the first thing to check if a workflow embed seems to do nothing.
Native capabilities and permissions. Reading a passport chip needs the React Native or Flutter SDK; a browser cannot do it. Address capture on iOS needs the location usage strings in your app, or the permission request crashes. If you plan to switch on a step that needs a native permission, ship the permission first.
The workflow ID itself. Workflows are scoped to one environment, so your sandbox and production workflows are different workflows. Keep the ID in configuration rather than hard-coded, so moving to a new workflow is a config change, not a code change.
Why changing live flows stays safe
Changing what every user sees from a dashboard sounds risky. Four properties of how workflows are versioned make it manageable.
Drafts are separate from what is live. Editing a published workflow only changes its draft. Integrations keep reading the last published snapshot until you publish again.
Every publish is versioned. Each publish bumps the version and appends an immutable history entry you can inspect or restore from. If a change goes wrong, you are restoring a known version, not reconstructing one.
Work in flight is not moved. A per-applicant session link carries the published configuration frozen when it was minted, so a re-publish never changes a link already in someone's inbox. A decision run is pinned to the version it started with, so a stricter graph does not re-decide an application that is part-way through.
Every result is attributable. Each verification records the workflow ID and the version that ran, and both appear on verification webhooks as workflowId and workflowVersion. Store the pair. Six months from now, when someone asks why an applicant was approved under looser rules, the version tells you exactly which rules applied.
One deliberate limit: a workflow's scope, what it verifies (for example an address-only or a face re-authentication flow), is editable until the first publish and then locked, because verifications and links already depend on what that ID means. To change scope, create a scoped copy, which starts as a new draft under a new workflow ID.
Rolling out a change
A workflow change reaches every user on their next verification, which is powerful and also means there is no gradual rollout by app version. Treat a publish like a deployment:
Make the change in the sandbox workflow and exercise every affected path with published test IDs.
Check that each branch of the decision graph ends on a status, and that any new step's native permissions are already in your shipped app.
Apply the same change to the production workflow and publish.
Watch the first results by
workflowVersion: approval, review and decline rates, and review queue volume.If something is wrong, restore the previous version from the history and publish it.
Tell your support team what changed; users will notice a new step before your dashboards do.
The rule of thumb
If it describes the flow, put it in the workflow and change it by publishing. If it describes the person, the device or what your app does with a result, it belongs in code and changes with a release. Build the integration once around a workflowId, keep your SDK reasonably current, and most of what used to be a release becomes a publish.
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.
