Lightbulb A clear path from application to approval.
An individual, a business and a partner can need different evidence. Build an onboarding workflow that requests the right items and lets a reviewer send back only what needs correcting.
Project terms and handover
You can commission this work independently of Lightbulb Partners Agent. Before building, we agree who may access your data, how ownership and licensing work, and how your team will test and accept the handover.
| Requirement | Status | Owner |
|---|---|---|
| Business details | Received | Operations |
| Signing authority | Clarification requested | Applicant |
| Provider pack | Awaiting review | Reviewer |
The reviewer can reopen one item and keep the rest of the file intact.
Designing the workflow
Make the rules visible to applicants and staff.
-
Map the paths into the service
Identify the client types, products and providers that change the questions. Agree which records can carry forward and which require fresh evidence.
-
Collect and correct one item at a time
Let applicants save progress and return to their checklist. Explain what is missing and keep each correction attached to the original request.
-
Keep the approved version
Freeze the provider pack at approval. If key evidence changes, show the difference and request fresh signoff. Track sent, acknowledged and approved separately so a person can check an uncertain handoff before anything is resent.
Illustrative builds
Three ways to use a case workflow.
The evidence and decision rights come from your process. These examples show what the team might commission.
Entity-specific onboarding
A business payments service uses different paths for a sole trader and a company. Its team checks signing authority before releasing a provider pack.
Partner accreditation
A platform collects partner details and supporting documents, routes exceptions to its reviewer and keeps renewal dates against the approved record.
Employee or contractor setup
An accepted offer starts the right checklist. The new hire supplies requested documents, Legal reviews the agreement and Finance confirms the payroll or supplier handoff.
Explore an example
One service, two application paths.
These are example requirements for a hypothetical provider. The actual checklist and approval rules come from the organisation commissioning the build.
If the applicant is an individual
The applicant provides contact details and the evidence specified for that service. If a name differs across the supplied records, an operations reviewer checks it. The receiving team gets the completed individual checklist, approved evidence references and the reviewer’s decision.
If the applicant is an organisation
The form also asks for entity details, an authorised contact and evidence of who may sign. If signing authority is unclear, a designated reviewer requests clarification. The receiving team gets an organisation checklist, confirmed signatory details and a record of approval.
Where onboarding fits
Keep the rest of the service connected.
If partners refer applicants or customers need ongoing access after onboarding, the same case can sit inside a wider client product. We agree which system owns the record and what gets handed over.
Project enquiries
Which application keeps coming back?
Describe one applicant type, the evidence that causes delays and the team that approves the file. We’ll use that example to scope the first release.