> For clean Markdown of any page, append .md to the page URL. > For a complete documentation index, see https://docs.yunojuno.com/llms.txt. > For AI client integration (Claude Code, Cursor, etc.), connect to the MCP server at https://docs.yunojuno.com/_mcp/server. # 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: | Workflow moment | What the checklist is deciding | | ------------------------------------------------------------------------- | ----------------------------------------------------------------------- | | [**Before offer**](/client-api/contracts/checklists-offer-retrieve) | Whether the hirer can send the contract to the contractor | | [**Before acceptance**](/client-api/contracts/checklists-accept-retrieve) | Whether the contractor can accept the contract and begin the engagement | --- ## Actors | Actor | Who they are | What they do | | -------------- | --------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------ | | **Hirer** | A person at the client organisation managing work, approvals, and contracts | Reviews client-side blockers and warnings, and uses checklist outcomes to understand whether a workflow can move forward | | **Contractor** | The independent worker being engaged through YunoJuno | Resolves onboarding, profile, and acceptance requirements that are needed before work can begin | | **Platform** | Automated YunoJuno evaluation logic | Decides which checks apply, evaluates them against the current state, and determines whether the step is blocked | --- ## 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. ```mermaid flowchart TD Action["User reaches an important workflow step"] Evaluate["YunoJuno evaluates the relevant checklist"] Pass["Step can proceed"] Resolve["User resolves outstanding items"] Action --> Evaluate Evaluate -->|No blocking issues| Pass Evaluate -->|Blocking issues found| Resolve Resolve --> Evaluate ``` 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.