Setting up your review workflow

Tavorly gives you the mechanism. The policy is yours, and it is worth deciding deliberately rather than discovering it.

Decide who approves

Approver is a role, and roles are assigned on Users. See Inviting your team.

Appoint at least two people who can publish — Approvers, Brand admins, or a mix. Creators cannot publish their own work, which is the point of the role; but if your one Approver is on holiday, nothing your Creators write can reach the line until they are back. Two is not bureaucracy, it is the difference between a menu change waiting an hour and waiting a week.

Appoint people who know the food, not people senior enough to be trusted. An approver’s job is to catch a wrong temperature, a missing allergen or a build that does not work at the pass. Seniority is not the qualification; knowing the kitchen is.

Understand what Tavorly does and does not enforce

Enforced	A Creator cannot publish. Ever.
Enforced	Approving publishes immediately — there is no second gate.
Not enforced	An Approver may publish their own work.
Not enforced	Anyone with the role can decide; submissions are not assigned.

If your brand needs “nobody publishes their own change, ever”, that is a rule you hold your team to. Tavorly will not stop an approver publishing their own recipe, and the audit trail will show they did. Decide whether you want that rule, tell people, and use the trail to check — see What gets recorded.

The shared-pool design is deliberate: routing every submission to one named person is how a queue becomes one person’s bottleneck and, eventually, a rubber stamp.

Tell approvers what to actually check

An approver looking at a diff with no brief will check spelling. Give them a short list. A reasonable starting point:

• Temperatures and control points — is a CCP marked where one is needed, and is the number right? See Food safety.
• Allergens — did new ingredients get tagged, or arrive untagged from an import?
• Quantities — do they scale to the portion this kitchen actually serves?
• Does the build work at the station it is assigned to?
• Does the Front-of-House description still match the dish?

And the one Tavorly surfaces for them: the blank-recipe warning. A recipe with no ingredients and no procedure can be approved, and will warn. Reject it unless the dish genuinely has no build.

Ask for useful notes

The submitter’s note is shown to the approver and kept with the revision forever. “Switched to the new lemon supplier — ratio unchanged” tells the next person what to check. “update” does not, and in a year it is the only record of why the dish moved.

Make a one-line convention: what changed, and why. It costs the author five seconds and saves the reviewer a diff.

Watch the queue, not just the recipes

Your dashboard’s Awaiting review tile counts the queue. A number that never drops means your approvers are a bottleneck; a number that drops instantly, always, means they may not be reading. Neither is visible from inside the queue itself.

Rejecting well

Reject & send back returns the recipe to its author as a draft with your note attached. Nothing is lost. Say specifically what to change — the example Tavorly itself offers is the right register: “Cook temp is too low for chicken – bump it to spec.”

A rejection with no reason is a round trip nobody learns from, and it teaches authors to resubmit unchanged and hope.

Related

• The approvals queue — the mechanics
• Roles, and what each one can do