Workflow runs

When a workflow runs

Once a workflow is configured under Customer KYC workflows, OneView runs it without anyone starting it by hand. There are two triggers:

• Onboarding — the onboarding workflow for the customer's type runs when the customer is created from a verification.
• Scheduled — the workflow for the customer's current risk band runs each time their review falls due, at the frequency saved for that band. A customer reviewed quarterly falls due again about three months after their last review.

A customer who is not in a risk band has no scheduled review. Bulk-imported customers are not onboarded automatically; that is a separate operator action, confirmed against its projected cost, described under Onboarding a bulk-imported batch below.

Each run records the workflow version it used, so an outcome remains readable against the policy that produced it even after the workflow has been changed.

The Runs tab

Open Customers → Workflows and select Runs. The tab requires customers:workflows:runs:read and is hidden without it; a user who has it sees Workflow runs and the runs OneView has recorded, newest first.

Filter with All bands and All statuses, and use the refresh control to pick up runs that have progressed while the page was open. The list shows:

Before any run exists the tab shows No workflow runs — Onboarding and scheduled workflow runs will appear here once OneView has run them. That is the expected state for a newly configured installation.

One run in detail

Select a run to open Workflow run. It states the customer, band, trigger, status, workflow version, and the due, started and completed times, followed by Check outcomes — one row per check, with its Outcome, a Detail where the check recorded one, and when it was Recorded.

Per-check outcomes

A run's status describes the run; each check inside it carries its own outcome.

A skip is not a failure

A skipped check is a neutral, recorded outcome. It means the run behaved exactly as configured and OneView declined to make a vendor call it could not make meaningfully — it is not a fault, and it says nothing adverse about the customer. Only Failed indicates something went wrong, and the interface styles the two differently for exactly this reason.

Two skips are worth understanding before they appear:

• Nothing stored to check against. A check with no stored value is skipped rather than failed. A customer with no BVN recorded is not a customer who failed BVN verification, and treating the two alike would put a mark against a customer for a gap in the institution's own records. Supply the missing value and the next run picks the check up.
• International Passport can never run automatically today. No passport number is captured anywhere in OneView, so a passport check has nothing to run against and cannot be selected into a workflow at all. Run it from its own International Passport verification page when it is needed.

A skip for the monthly execution limit means the allowance in the license was exhausted, not that the check is misconfigured. Review the installation's usage on the Dashboard, and see License management.

What a run can change

A PEP Screening or Sanction Screening result from a run can change the customer's risk level, in the same way a screening at customer creation can. Because the risk band determines the review frequency, a customer moved to a higher band by a screening result is thereafter reviewed more often, using that band's workflow. No other check changes a customer's risk level.

The customer's next review

A customer's KYC tab shows Next KYC review — When OneView next runs this customer's configured KYC workflow — as a date, or No review scheduled.

No review scheduled is a statement of fact, not an error. It appears when the customer is not in a risk band, or their band's workflow carries no review frequency. Placing the customer in a band, or configuring that band's frequency, gives them a scheduled review.

Onboarding a bulk-imported batch

Importing customers from a file does not run their onboarding checks. A large import would otherwise become thousands of billable vendor calls the moment the file was accepted, so the decision is left with an operator who can see what it will cost.

Running them requires both customers:bulk_import and customers:workflows:manage. Importing customers and committing the institution to the vendor spend of checking them are separate rights: an operator holding only customers:bulk_import can import a batch and view what onboarding it would run, but is not offered the button that starts it.

1. Open the batch from Customers → Bulk import.
2. Select Run onboarding checks. OneView works out what the batch would run before asking anything.
3. Read the confirmation. Run onboarding checks? states the real projected numbers, such as This will run 4,000 checks across 1,000 customers. Each check that reaches a vendor is billable., and lists Checks that will run per customer.
4. Select Run onboarding checks to confirm, or Cancel to close without running anything.

OneView confirms with the number of runs queued. The runs then appear on the Runs tab with the trigger Onboarding, and move from Pending to Completed as they are worked through.

Batches imported before this release cannot be onboarded this way

OneView records which batch created a customer only for imports performed by this release and later. For a batch imported before it, that link does not exist, so the projection finds no customers and the confirmation reports No onboarding checks are outstanding for this batch. with nothing to confirm.

This is a permanent limitation of those older batches, not a fault to troubleshoot. To onboard customers imported earlier, run the checks they need from each Sub-module's own Verification page, or re-import them and use the button on the new batch — checking first that re-importing suits the institution's own duplicate-handling policy.