Checklists
What is a Checklist?
On the YunoJuno platform, a checklist is the set of checks that determines whether an important workflow step is ready to go ahead.
Instead of asking a user to infer readiness from a record alone, YunoJuno evaluates the relevant requirements and presents them as a clear set of outcomes. A checklist shows what is already satisfied, what still needs attention, and whether the next step can proceed now or must wait.
Checklists are one of the main ways YunoJuno turns operational policy into something usable at the point of action.
Where Checklists Appear
Within the current public API, checklists are exposed at two moments in the contract lifecycle:
Actors
How a Checklist Works
A checklist is a live evaluation of the current workflow state.
It is not a static to-do list saved once and then carried forever. The result depends on the record, the people involved, and the supporting information available right now. If something changes, the checklist can change too.
This gives users a clear answer in the moment rather than forcing them to guess whether the next step is ready.
What a Checklist Can Contain
Checklist items usually fall into a few broad categories:
- missing information that must be completed
- approvals or confirmations that have not yet happened
- compliance or eligibility requirements that are not yet satisfied
- workflow-state conditions that make the step temporarily unavailable
- warnings that are worth surfacing even when they do not prevent the action
Some checks are purely informative. Others are decisive because they prevent the next step until the issue is resolved.
Blocking and Non-Blocking Checks
Not every checklist result has the same impact.
A blocking check means the action should not go ahead yet. A non-blocking check provides context, reassurance, or a warning, but does not stop progress by itself.
This distinction is important to the user experience. It means YunoJuno can do both of these things at the same time:
- protect important workflows from moving too early
- still surface useful context without turning every issue into a hard stop
In practice, that makes checklists feel like operational guidance rather than just validation errors.
Custom Field Checks
Alongside the standard checks, checklists can be extended with additional checks configured against a your own custom fields. This lets you bring your internal data requirements into the same readiness evaluation, so the checklist reflects both YunoJuno-level rules and your specific operational policy. When configured, these custom field checks appear in the checklist output in the same way as any other check, and can be blocking or non-blocking depending on how they are set up.
Contract Checklists
Before Offer
An offer checklist runs before the contract is sent to the contractor.
Its job is to answer a hirer-facing question: is this contract ready to be issued?
Typical offer-time issues include missing commercial information, unresolved approval requirements, spend controls, or setup steps that must be completed before the contract is shown to the contractor. If a blocking offer check fails, the hirer must resolve it before the offer can be sent.
Offer checklists are mainly about making sure the contract is complete and internally ready.
Before Acceptance
An acceptance checklist runs after the contract has been offered and before the contractor can accept it.
Its job is to answer a different question: is everything in place for this contractor to begin the engagement under this contract?
Typical acceptance-time issues include payment setup, supporting documentation, insurance, employee-record requirements, or other readiness conditions that only become relevant once the contractor is about to commit. Some of these are contractor actions. Others are useful for the hirer to understand because they explain why acceptance is still blocked.
Acceptance checklists are about readiness to start, not just readiness to send.
Different Guidance for Different People
The same underlying issue often needs to be explained differently depending on who is looking at it.
A contractor may need a direct instruction about what they must complete next. A hirer may need a status-oriented explanation of why the contractor cannot proceed yet. YunoJuno supports that difference in perspective so the feature can guide the right person, in the right language, at the right time.
This is one of the reasons checklists work well across both YunoJuno’s own product surfaces and more integrated client workflows.
