Approval queue: everything waiting on you, in one place.

Four sales waiting for approval

Each row is an open task. It shows the record that asked for approval, the step it is at, the flow it came from, the deadline and the date it entered. You only see what is yours, through your role or because the task was assigned to you.

The decision happens on the record itself

When you open a pending item, you land on the same record form, now in task mode. The buttons become the flow's outcomes: Approve, Send back and Reject. If the step requires it, the comment becomes mandatory.

{{-- The SAME record form gets the decision buttons --}}@if($that->wfTaskMode)<mad-form-section title="Decision" icon="message-square"><mad-textarea-field name="wfComment" label="Decision comment" rows="2" /></mad-form-section>@endif<mad-form-actions>@foreach($that->wfOutcomes as $key => $meta)<button class="mad-btn mad-btn-{{ $meta['intent'] }}">{{ $meta['label'] }}</button>@endforeach</mad-form-actions>

You design the flow, you don't code it

Steps, approvers, deadlines and conditional paths live in the workflow editor. The queue and the decision buttons come out of that design. Your controller doesn't gain a single line of flow code.

When to use the approval queue

Use the queue when a decision has to go through someone before moving on. Everyone sees what is waiting on them, with a deadline, and the decision is recorded.

• Discounted sale. The sale stops at sales approval before invoicing.
• Credit review. A finance-only step, with a deadline and overdue items highlighted.
• Purchase order. A conditional path sends certain purchases through one extra step.
• Vacation and expense claims in HR. The manager approves, sends back or rejects, with a comment.
• Contract with two departments. Legal and finance decide at the same time, in parallel branches.

If all you need is to change the status by dragging a card, with no deadline or owner, a kanban does the job. To split a long record into parts, use the wizard: there the steps belong to the form, not to an approval. And the roles that receive the tasks are defined in system permissions.

What you configure

The queue comes out of the flow design. That is where you decide:

Who decides

Each step goes to a role or to a person, and the task shows up in the queue of whoever was chosen.

Deadline

Each task has its own deadline, and overdue ones are highlighted.

Step outcomes

The possible decisions, such as Approve, Send back and Reject. Each one becomes a button on the form.

Mandatory comment

Depending on the decision, a comment becomes required. A rejection can ask for the reason.

Conditional paths

The flow takes different paths depending on a condition you define.

Parallel branches

Two steps run at the same time, each with its own approver.

What goes into the Laravel project

The decision happens on the record form: a class in app/Control and the view with <mad-form>. The flow talks to it through a few properties:

• The form knows when it's a task. The wfTaskMode property tells Blade when to show the decision section.
• The buttons come from the flow. The wfOutcomes list carries each outcome with a label and style. Change the flow and the buttons change, without touching Blade.
• The comment is a regular field. It is a <mad-textarea-field> named wfComment, with a label and height you can adjust in Blade.
• A custom action becomes a permission. On an approval button outside the flow, the #[MadPermission('Approve quote')] attribute on the method creates a permission with that name on the Roles screen.

Like every MadBuilder screen, these files open in your editor, go into your Git and accept hand-written code in protected blocks, which stay there when the screen is regenerated. See how the code is generated.

Questions about the approval queue

And more

See also the Wizard or the page types.