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.
Within the current public API, checklists are exposed at two moments in the contract lifecycle:
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.
Checklist items usually fall into a few broad categories:
Some checks are purely informative. Others are decisive because they prevent the next step until the issue is resolved.
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:
In practice, that makes checklists feel like operational guidance rather than just validation errors.
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.
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.
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.
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.