Laravel Process Approval turns a model into a multi-step sign-off

A package for models that need sign-off before they take effect

Laravel Process Approval is a Laravel package that makes it easy to add approvals to your application, and the README narrows the use case: it enables multi-level approval workflows for Eloquent models, for teams that have models requiring review and approval from multiple approvers before execution. The audience is a developer building an internal business application, typically a request or ticket style model, where a single approver is not enough and where the rule of who approves in which order needs to live somewhere other than a controller. The package requires Laravel 10.0 or later. It also draws a boundary early and clearly, because the package relies on an existing Role management, which can be a custom role management or another package such as Spatie's laravel-permissions. That is a meaningful design decision rather than a detail, and it means the package is one layer of a two layer setup. It manages who must approve and in what order. It does not decide who is allowed to approve, because that is the job of the role system you already have. The licence is MIT and the package is distributed through Packagist, so the composer install is the whole entry story.

How approval flows and steps are stored in your database

The data model is the core of the package. The package relies on Approval flows and steps on your default database, and that is what enables multiple approval flows to exist within the system at the same time. A flow is a named procedure, for example a fund request, and a step is one stage inside it, bound to a role and to an approval action. Because the definitions live in tables rather than in a config file, a flow can be created, extended or removed at runtime through the artisan commands, or managed by your own application code, since the README explicitly says you can implement your own way of creating and managing the flows. The package ships four migration files, which it tells you to run before using it. The opt-in UUID story is a second set of migrations, and the README warns that if you publish migrations manually you must set load_migrations in the config file to false to avoid running migrations twice, while the install command sets that flag for you. The design is therefore: a schema for flows, steps and the approval records, plus a trait that attaches the workflow behaviour to any model you choose.

Installing the package and running its migrations

Installation starts with composer, and the package is pulled in from Packagist:

composer require ringlesoft/laravel-process-approval

The UUID variant has its own install command, which publishes the right migrations and updates the published configuration:

php artisan process-approval:install --uuids

If you have already published files and want them replaced, the same command takes a force flag:

php artisan process-approval:install --uuids --force

You then run the migration, which the README asks you to do before you start using the package:

php artisan migrate

If you would rather publish files by hand, the package registers publishable configuration, migrations and views, and the tags let you pick one set at a time. The available tags are approvals-migrations, approvals-migrations-uuids, approvals-config, approvals-views and approvals-translations, and the config file is published with:

php artisan vendor:publish --provider="RingleSoft\LaravelProcessApproval\LaravelProcessApprovalServiceProvider" --tag="approvals-config"

One operational point to carry into your own notes. Running process-approval:install sets the load_migrations flag in the published config to false so the same migrations do not run twice, and publishing the migrations manually means you have to make that change yourself.

Creating flows and steps from the command line

The artisan commands are the fastest route to a working configuration, and they are interactive where you would expect them to be. A new flow is created by naming it:

 php artisan process-approval:flow add FundRequest

Steps are added to a flow with the step command, which shows a list of available flows, and after you pick the flow you then select the role and the approval action. The command is `php artisan process-approval:step add`.

The removal commands mirror the creation ones. The flow remove command shows the available flows and lets you select the step you want to delete, and the step remove command shows the available steps and lets you select the one to remove, with the selection made by pressing enter. There is also a listing command, the flow list command, which shows all available flows and steps, and that is the fastest way to see the current configuration before you change it. The command set is deliberately small, four verbs over two nouns, and the interactive selection means you do not need to remember the identifiers of flows or steps, although you do need a role system with the roles already defined, since the role is chosen at the point where the step is created.

The model side: an interface, a trait and one callback

Attaching the workflow to a model takes three steps in the README. First the model implements the ApprovableModel interface:

class FundRequest extends Model implements ApprovableModel
{

   // Your model content

}

Second the Approvable trait is applied:

class FundRequest extends Model implements ApprovableModel
{
    use \RingleSoft\LaravelProcessApproval\Traits\Approvable;
   // Your model content
   
    public function onApprovalCompleted(ProcessApproval $approval): bool
    {
        // Write logic to be executed when the approval process is completed
        return true;
    }
}

Third, and this is the part that decides what actually happens in your domain, you implement the onApprovalCompleted method. The README describes it as the one callback the package relies on to commit the last approval and mark the approval process as completed, and you return true to finalise the approval or false to roll back the last approval, which is useful when you need to perform specific tasks when the approval procedure completes. Note the scope of that guarantee. The callback is about the final approval and a rollback of that last approval, not a transaction over the whole workflow, so the code you write inside it is responsible for the side effects that must happen together with the state change.

A Blade component for the actions, styled by css_library

The user interface is a single Blade component that you place on the show page of your model and pass the model instance to:

    <x-ringlesoft-approval-actions :model="$fundRequest" />

That is the entire front end integration. The approve and reject controls that a user sees come from the package views, and the styling is chosen by a configuration setting named css_library, since the UI is currently implemented using tailwind, bootstrap or vanilla css. You switch between the frameworks by modifying that setting in the configuration file, and if the packaged views are not what you want, you can publish them with the approvals-views tag and edit them, which is the normal escape hatch for a package that renders into your own layout. Translations are published separately under the approvals-translations tag, so the same component can carry your own wording for the actions. For an internal tool, that combination, a default component, a switchable CSS library and publishable views, is a reasonable amount of customisation without taking on the work of building an approval screen yourself.

The limitation: a role system is a precondition, not a feature

The clearest constraint is the dependency on roles. The package relies on an existing Role management, and the configuration section makes that concrete. The roles_model setting specifies the full class name of the model related to the roles table, defaulting to Spatie's laravel-permissions Role model, and the users_model setting specifies the model that represents the authenticated users, defaulting to App\Models\User. A team that has no role management already has to build or adopt one before this package becomes usable, which is a larger project than installing a Composer dependency. The second constraint is the scope of the workflow itself. The package is about approvals on Eloquent models, with flows and steps defined in the database, so it does not cover a workflow that spans several models, an approval granted outside the application such as by email, or a delegation when an approver is unavailable. A third point is the age of the code. The releases listed are 1.1.5 on 2026-04-20, 1.1.4 on 2025-12-19 and 1.1.3 on 2025-10-23, and the last push to the repository was on 2026-04-20, so the most recent activity in the project is a little over six months old and the version you install should be checked against the features you actually need.

A package workflow versus approvals you build yourself

The realistic alternative is to implement the approval logic inside your own application, which for a single-model request workflow is not unreasonable. A hand-rolled version would keep a status column on the model, check the approver's role in a policy, and decide what to do when the status changes. The difference in approach is what the package supplies. The hand-rolled approach gives you total control and no dependency, but you build the flow definitions, the step progression, the rejection and restart behaviour, the audit record of who approved what and when, and the user interface that lets a reviewer act. The package gives you those pieces, and the pieces are specific rather than generic, since a flow and a step are data rows tied to a role and an action, and the flow list and step remove commands exist so that an administrator can adjust the workflow without a deployment. The tradeoff is that you accept the package's data model, its Blade component and its config keys, and you must supply a role layer to fit underneath it. For many internal applications the deciding factor is not capability but how many approval screens the organisation will have to build over the next two years.

Editorial conclusion

Laravel Process Approval fits a Laravel 10 or later application that already manages roles and needs a model to be approved by several role holders before it takes effect, and where you want the flow definitions stored in the database rather than in code. It does not fit a team without a role management layer, since roles_model and users_model are configuration points the package expects you to fill in. Before adopting it, confirm the last published version, 1.1.5 from 2026-04-20, carries the features you need, because the repository has not been pushed to since that date.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. README
4. Releases
5. ringlesoft/laravel-process-approval on GitHub