Do not let incomplete intake become accepted setup in STAR.
Client Onboarding
Client Onboarding is the governed front door for new clients and new jobs into STAR. It gives incomplete work a governed place to live until the firm is ready to approve it, preserve exactly what was approved, and create the STAR records behind it. Start from a Prospect or an existing STAR Client. Create a Job Opportunity. Save it as a real draft, validate it in stages, see the approval path before submission, handle rare exceptions cleanly, and create STAR records only when the firm is ready to stand behind them. What was approved stays preserved. The live STAR Client and Job continue afterward.
new Prospects and existing STAR Clients • Job Opportunities before live STAR Jobs • save-level and submit-level validation • visible approval preview • controlled STAR insertion • frozen approved snapshot
The same governed path supports both brand-new clients and existing-client new work
Job Opportunities keep proposed work separate from live STAR Jobs until approval
Save-level draft rules stay distinct from submit-level readiness rules
The user can see the approval path before submission instead of discovering it afterward
Submitted work locks until it is approved or rejected for correction
Approved opportunities freeze while the live STAR records keep moving afterward
Where accepted setup starts going soft
Most firms do not break here because intake stops moving. They break because a client or job record gets created while the firm is still carrying conditions it intends to settle later.
The billing contact is not final. Job detail still needs clarification. A required document is assumed to be coming. An unusual handling decision is understood verbally but has not been approved cleanly. Once the record exists in STAR, uncertainty starts reading like settled setup and follow-up becomes someone else’s repair work.
What that softness turns into
an official-looking STAR record before the firm has finished deciding what it is accepting
rekeying, correction, and clarification work pushed into tax, audit, billing, client service, and operations
exceptions that fade into side follow-up instead of staying visibly owned
a system of record carrying uncertainty as if it were settled setup
Why it costs so much later
Onboarding is one of the few moments where the firm can still stop bad setup before the rest of the system has to live with it. Weak entry rarely stays contained. It comes back later as billing friction, delayed starts, cleanup, weak reporting context, and teams inheriting records they still cannot trust.
What Client Onboarding governs before setup becomes real
Client Onboarding is not just an intake form with approvals. It is a STAR-aware operating layer around how new clients and new jobs enter STAR, so incomplete work can stay governed before it becomes accepted setup.
Start from the right account context
Work can begin from a new Prospect or from an existing STAR Client already synced into the app. A major day-to-day use case is starting from an existing client, reviewing the client, related entities, prior opportunities, live Jobs, and files, and then creating a new Job Opportunity from there.
Hold proposed work before it becomes real setup
A Job Opportunity is the app-native pre-STAR job. It is where the firm collects detail, validates the request, previews approvals, handles exceptions, and decides whether the work is ready to become real. Proposed work stays separate from live STAR Jobs until the firm approves it.
Validate in stages instead of pretending everything is known
Save & Continue enforces a configured minimum for a real draft. Submission enforces a stricter readiness standard. Incomplete work can live safely in the product without being treated as approval-ready, while meaningless junk is still kept out.
Approve first, create STAR second
The approval path is visible before submission, rare scenarios can trigger targeted submission-time prompts, and STAR records are created only when the firm is ready to stand behind what it is accepting. What was approved stays preserved. The live STAR Client and Job continue afterward.
What changes for the firm
The firm no longer has to choose between forcing half-settled work into STAR and leaving it scattered across notes, email, memory, and side follow-up. Instead, incomplete work gets a real governed place to live until the firm is ready to approve it, preserve it, and create the STAR records behind it in a controlled way.
The path should be visible before commitment
The workflow is staged on purpose. Incomplete work can live safely in the product without being treated as approval-ready, and the user can see the path before the request enters workflow.
Save & Continue creates a real draft threshold
A new Account or Job Opportunity begins with Save & Continue. The app enforces a configured minimum at save time: enough to keep meaningless junk out, but not so much that users must know everything immediately. That is the threshold for work-in-progress drafts.
The full working surface appears only after the draft is worth keeping
Once the save-level rules are satisfied, the form expands to expose the rest of the working surface, including files, Due Date Opportunities, and Approval Steps. Incomplete work can stay inside the product without lowering the standard for what counts as ready.
Submission uses a stricter readiness standard
Submitting for approval is a different threshold. Full submit-level validation applies here before the opportunity can enter the approval path. Rare submission-time dialogs can also appear for unusual mismatches, governance prompts, or risk questions without cluttering everyday entry.
Rejection is the controlled reopen path
Once submitted, the Job Opportunity locks and moves into Onboarding. Approvers can review, comment, approve, or reject. Rejection unlocks the record, preserves comments and step history, and lets the corrected request be resubmitted without losing auditability.
The path is visible before submission
Approval Steps appear on the form before the user submits. As values change, the approval path updates dynamically with them. Depending on the request, steps can appear, disappear, or reroute to different approvers before the request enters workflow. The user should not have to guess what the system is doing or discover the logic only after commitment.
What submission changes
Submission locks the Job Opportunity so values cannot change quietly underneath approvers. Comments carry forward through the process, and the workflow stays auditable while the request moves through review instead of being reshaped midstream.
What approval creates — and what it preserves
Approval is the point where governed pre-STAR work becomes real STAR setup. It is also the point where the product preserves exactly what the firm approved.
STAR creation is controlled and dependency-aware
When the first Job Opportunity under a new Account is approved, the app creates the STAR Client, the STAR Job, and related STAR internal records inside one SQL transaction. If the work belongs under a new child Account that itself belongs under a new parent Account, the parent is created first, then the child, then the Job, in the same controlled sequence.
That matters operationally and technically. The product works with STAR’s underlying structure, respects dependencies, preserves the approval decision, and creates live records in a controlled way instead of improvising around the system of record.
The Account stops being a draft and becomes a synced STAR Client
A Prospect becomes a STAR Client only when at least one related Job Opportunity is approved. After STAR creation, that Account becomes read-only inside Client Onboarding and continues as synced STAR data.
Later approvals can create more STAR Jobs under the same Client
Once the Client exists in STAR, future approved Job Opportunities create additional Jobs under that same Client. That is why existing-client new work is so central to the product story.
The approved opportunity and the live STAR Job remain distinct
The approved Job Opportunity stays frozen as the record of what the firm accepted. The live STAR Job continues afterward as a synced current record. What was approved stays preserved. What the live STAR record later becomes can continue to change.
Why proposed work and accepted setup stay separate
The product is not a generic front end for form entry. It uses a record model that keeps incomplete work governed before it becomes accepted setup.
Accounts
An Account is the app’s umbrella record for something that may be either a pre-STAR Prospect or an existing STAR Client. It can also be a parent or child account inside STAR’s two-level relationship structure.
new Accounts can begin as app-side Prospects
existing STAR Clients appear as synced Accounts
related parent and child entities stay legible before new work is added
Job Opportunities
A Job Opportunity is the app-native pre-STAR job. It is where the firm collects detail, validates the request, previews approvals, handles exceptions, and decides whether the work is ready to become real.
proposed work stays separate from live STAR Jobs
new-client setup and existing-client new work use the same governed layer
the approved opportunity remains as the preserved record of what the firm accepted
Jobs
Jobs are live STAR Jobs synced into the app. That includes Jobs created through Client Onboarding and Jobs created through other STAR processes, so the user sees current reality rather than a sealed workflow island.
live STAR Job status stays distinct from Job Opportunity workflow status
approved opportunities create new STAR Jobs under control
the client view can show account context, opportunities, live Jobs, files, and status together
Why the model matters
This is what keeps the product from collapsing into generic intake. The firm can hold proposed work and pre-STAR account records inside the app, preserve what was approved, and keep showing the live STAR context afterward without forcing everything into STAR too early.
Built for the STAR environment firms already live in
Most firms adopt Client Onboarding after years of STAR usage, not before. The product is built for that lived-in reality.
Existing-client new work is central
A major use case is starting from an existing STAR Client and creating a new Job Opportunity under that Client, with validation and approvals happening before the new STAR Job is created. First-time client setup matters. Existing-client new work matters just as much.
The app coexists with current STAR reality
On day one, the app can already show many Accounts and many Jobs because those are synced from STAR, even while there are few or no Job Opportunities yet. That is normal. Opportunities accumulate only as new work starts flowing through Client Onboarding.
The workflow stays visible from either side
Status is not trapped inside one window. It can surface on the Job Opportunity itself, inside account windows, in related parent-child views, and in the main grids, including combined client statuses such as Onboarding (Active).
Visibility follows the firm’s real operating model
The main grids are permission-based and customer-specific. The user can work from Accounts, Job Opportunities, My Items to Approve, My Job Opportunities, and live Jobs according to the dimensions the firm cares about, whether that is office, service line, book of business, or something more specific. The product works with the firm’s actual visibility model instead of pretending everyone sees the same world.
No second identity model to manage
In the implementation shown, the app identifies the user from the Windows domain account and maps that identity through STAR’s staff model. The point is not novelty. It is continuity. The workflow lives inside the firm’s actual operating environment instead of inventing a second one.
The software should absorb the avoidable complexity
These are not decorative interface choices. They are part of why the product holds up under legacy data, repeat work, similar staff names, and real approval pressure.
Search is built for real operational lookup
The app uses synced, precompiled tables optimized for its own architecture, which is why major grids feel immediate even in lived-in data. Search tokenizes a phrase and matches all words across configurable searchable fields, including hidden backend fields where appropriate.
That matters in the kind of lookup firms actually do. A search like Amine Fayad can still find Fayad, Amine. The system is built to help the user find truth instead of hoping the exact stored string happens to match.
Sorting behaves like an operational grid, not a flat list
Major grids support chained multi-column sorting. Users can layer primary, secondary, and further sort levels so large client populations, approval queues, and staff lists stay workable instead of arbitrary.
Role selection gives the user enough context to choose correctly
Fields such as Job Partner use searchable inline selection grids rather than weak dropdowns. Lists are pre-filtered to eligible staff and can show contextual columns such as office, service line, status, and skill level when names are similar and assignment rules are real.
Hierarchy and defaults reduce partial entry
For structures such as Service Line Group, Service Line, and Job Type, the user chooses the leaf and the app fills the linked hierarchy together. Client-level defaults can also flow into a new Job Opportunity so repeat work starts faster without blind carry-forward.
The account window is part of the working surface
Account views combine top-level client details, related child accounts when applicable, related Job Opportunities, related live Jobs, and attached files. From an existing STAR Client account, users can add files, add a child account, or create a new Job Opportunity with the relevant context already in front of them.
Operational details that make the workflow hold up
Files can be attached to the Account or the Job Opportunity. Due Date Opportunities can be added after Save & Continue. Formula-based job naming can derive the future STAR Job name from structured choices rather than forcing freeform drift. Together, these design choices reduce cleanup, keep context attached to the right record, and make routine onboarding work easier to enter correctly the first time.
The firm’s real rules can stay inside the workflow
Client Onboarding is not limited to STAR’s built-in fields or a narrow set of hardcoded checks. Firms can keep their real operating logic inside the governed path.
Customer-specific STAR fields can live inside the governed workflow
That can include staff-based fields, custom lists, allocation logic, referral or acquisition metadata, and other firm-specific fields the workflow needs to collect before setup becomes real.
Validation can be simple, conditional, or fully programmable
The app can enforce straightforward rules such as invalid fiscal combinations or percentage totals equaling 100%, but it can also use pluggable stored-procedure logic when the firm needs deeper governance.
The workflow can show why an approval step exists
Routing is only useful if people can understand it. The product can explain why a step is present, which keeps firm-specific approval logic legible instead of mysterious.
Exceptional actions stay exceptional
Approvers can comment on approval or rejection. Steps can include multiple possible approvers. Privileged users can approve on behalf of another approver when needed, and tightly trusted administrators can force approve or force reject in rare cases. Those actions remain exceptional and auditable.
Why that matters
The product is not a sealed workflow box. Firms with real STAR complexity, real SQL capability, and real customer-specific fields do not have to flatten their operating rules into generic form behavior just to get governed workflow.
Adoption should feel lighter than the problem
Client Onboarding is usually introduced into an already-lived-in STAR environment, then proven in a contained rollout before broader expansion. It should reduce burden from the beginning, not create a second project for people who are already busy.
Start with the rules the firm actually wants enforced
Implementation typically begins with the fields, documents, save-level minimums, submit-level readiness rules, approval logic, exception prompts, and STAR setup behavior the firm actually wants governed.
Pilot in a contained slice of work
The better first rollout is usually one office, one service line, or one defined set of Job Types. That lets teams prove the workflow with live work before expanding it more broadly.
Expand once users trust the threshold
Broader adoption tends to follow once users trust that drafts can live safely in the app, approvals are routing correctly, and approved setup is entering STAR in a cleaner condition than before.
Why this does not have to become another firm project
This is where deep STAR fluency matters. The work can start from the firm’s real record model, role structure, hierarchy constraints, customer-specific fields, and operating rules instead of making the firm translate its environment into generic requirements first.
Common questions
Is this mainly for brand-new Clients?
No. A major day-to-day use case is starting from an existing STAR Client and creating a new Job Opportunity under that Client. First-time client setup matters, but existing-client new work matters just as much.
What if STAR already has years of history in it?
That is the normal starting point. Client Onboarding is designed to coexist with existing STAR Clients, existing STAR Jobs, migrated history, and Jobs created through other STAR processes. It governs what enters STAR next. It does not require the firm to start over.
Does it replace STAR?
No. STAR remains the system of record for live Client and Job maintenance. Client Onboarding governs the pre-STAR phase, preserves the approved Job Opportunity snapshot, and continues showing the live synced STAR Client and Job afterward.
Does it replace CRM?
No. CRM can still manage lead activity and pipeline. Client Onboarding takes over when the firm is ready to govern the transition into an actual STAR Client or Job.
Can it handle related entities, different onboarding paths, and custom STAR fields?
Yes. The app supports STAR’s two-level parent-child client structure. Requirements, templates, approvals, routing, validations, and customer-specific STAR fields can vary by service line, client type, Job Type, fee profile, risk, or other firm-defined rules.
What keeps the request from changing mid-approval?
Submission locks the Job Opportunity. If an approver rejects it, the record becomes editable again, comments and step history remain intact, and the corrected request can be resubmitted through the same governed path.