Automation Bundle Laravel Package

Getting Started

The uvdesk/automation-bundle provides the workflow engine for a UVDesk helpdesk: rules made of an event (trigger), a set of conditions (ticket/agent/thread attributes), and actions (assign, set priority/type, send prepared response, etc.). Day-to-day you spend most of your time in the workflow admin UI, not in code — the bundle's job is to let support leads change routing behaviour without a deploy.

Minimal setup:

1. composer require uvdesk/automation-bundle (this is a Symfony bundle that lives inside the UVDesk core framework; the release notes reference CHANGELOG-1.1.md on the automation-bundle repo).
2. Register the bundle with your kernel/bootstrap and run bin/console doctrine:schema:update --force (or the project's migrations) so the workflow/condition/action tables exist.
3. Clear cache (bin/console cache:clear) — workflow metadata is compiled.
4. Verify the DI wiring loaded by checking that the workflow listing screen renders and that your existing Workflow entities still enumerate.

Where to look first: the Workflow entity and its condition/action relations, then the workflow controller/twig views that render the builder. That trio tells you what is configurable versus what needs a custom extension class.

First use case: an "event = ticket created, condition = priority is High, action = assign to a specific agent/group + attach a prepared response" rule. Build it in the UI first to confirm the event fires, then replicate it in a fixture/seed so it is version-controlled across environments.

Implementation Patterns

UI-first, seed-second. Author workflows interactively to validate the condition editor, then export them as fixtures or a seeder so staging/production are not hand-configured. Workflows are data, not code — treat them like content and keep them in version control.

Compose, don't fork. Prefer several small single-purpose workflows (routing, escalation, canned-response) over one large rule. Condition evaluation is easier to reason about and you can disable one without losing the rest.

Extend via tagged services, not edits. Custom conditions and actions are the intended extension point — implement the bundle's condition/action interface and register the class as a service with the appropriate tag/attribute. Never patch vendor classes; you will lose the work on every release like 1.1.4, which included refactoring and removed unused methods.

Guard the ticket view path. v1.1.4 adds a filter for prepared responses on the ticket view. If you have overridden the ticket template (custom theme, extra JS around the reply box), re-test that:

• the prepared-response dropdown filters as expected,
• your overridden template still receives the filtered collection rather than a full unfiltered one,
• any custom AJAX endpoint you added for canned responses does not bypass the new filter.

Dashboard/search icon updates (v1.1.4). The workflows dashboard and search bar SVG icons changed. If you have a custom brand theme or an asset pipeline that patched those SVGs, diff the new templates before overwriting. Purely cosmetic, but a common source of "why does my forked template look broken" noise.

Workflow conditions changed in 1.1.4. Treat this as the one behavioural item in the release. After upgrading, run a regression pass over every workflow whose conditions use more than one row or mixed AND/OR logic — re-open each in the builder, save it once (to normalise the stored structure), and confirm the resulting rule matches intent. Then fire test tickets through the affected events.

Gotchas and Tips

• "Removed unused methods" is not guaranteed safe. Public or protected methods removed during refactoring only matter if you subclassed a bundle class. Grep your app for extends against automation-bundle classes and for calls to any method you did not see documented. Since this is a 1.1.x patch, treat it as non-breaking but verify your overrides.
• Cache is the usual suspect. Workflow changes that "don't apply" are nearly always stale metadata. Clear cache after any upgrade and after editing condition/action registration.
• Condition changes are silent data migrations. 1.1.4 touched condition handling; existing rows persist in whatever shape they were saved. Nothing will error, the rule just evaluates differently. Diff behaviour before/after on a staging copy rather than trusting the changelog summary.
• Prepared-response filtering is presentation-only. Confirm whether the filter is client-side or query-side before assuming it fixes performance on large response libraries — check the ticket view controller if the dropdown is still slow.
• Debug workflow firing by narrowing, not by logging in the action. Start with a condition that can only match one test ticket; if it fires, widen. Adding dump()/log calls inside vendor action handlers is a fast route to merge pain.
• Changelog discipline. 1.1.4's notes are a summary; the linked CHANGELOG-1.1.md carries the detail. Read it before upgrading, and pin the version in composer.json if you run UVDesk in production, since patch releases here include behavioural tweaks to conditions.
• Readme changes are worth a skim. Bundle readmes often pick up registration or configuration instructions that shift between minor versions — cheap to check, expensive to miss.