PLUGIN EXTENSIONS & CUSTOM FEATURES

A two-tier complaints desk layered over Fluent Support

A two-tier complaints desk layered over Fluent Support without forking it — field reps inside the helpdesk, the back office in control, and every rule enforced on the server.

0

core files modified

18

Fluent Support hooks used

15

hooks exposed

0

extra tables

WordPressPHPFluent SupportJavaScript

ClientManufacturer and B2B supplier, Italy (name withheld)
ChallengeFluent Support treats every agent the same: field reps could close, reassign and retag complaints. The client’s process needed a strict role split, a three-state lifecycle, a searchable complaint number, several owners per ticket, and a goods-collected sign-off from every responsible person.
DeliveryOne extension plugin: two roles, three statuses, grouped tags, complaint-number capture and search, primary owner plus co-assignees with tag-based auto-assignment, multi-party collection sign-off, Italian dates, a settings page, a documented API, training and handover.
StackWordPress, PHP, Fluent Support, JavaScript
TimelineFebruary to March 2026, about four weeks

The challenge

The client makes and supplies goods to business customers, and complaints arrive through the field: a sales rep visits a customer, hears about a defect or a wrong delivery, and needs to log it. The back office then owns the case — assigns a complaint number, arranges collection of the goods, and closes the ticket when the matter is settled. They already ran Fluent Support, and out of the box it did not fit: every agent had the same power, the status set did not match the three-step process the whole company used, there was nowhere to put the complaint number, one ticket meant one agent, and “goods collected” lived in people’s heads.

The requirements sessions fixed eight rules: two tiers, with reps opening and replying while only internal staff close, reassign or retag; exactly three visible statuses; tags in named groups with one tag per group; a searchable complaint number captured automatically from internal notes; a primary owner plus co-assignees with tag-based auto-assignment; a collection sign-off confirmed individually by every responsible person; absolute Italian dates; and all of it configurable by the client’s own admin after handover.

What made it hard: Fluent Support’s agent area is a Vue single-page application. No PHP templates to override, no hooks inside the ticket view — the screen reps see is rendered in the browser from JSON. That left two bad options: fork the plugin and lose every future update, or build a parallel interface and lose the product the client had already bought. The constraint that shaped every decision: the server must enforce every rule, and the browser layer must survive both Vue re-renders and Fluent Support updates.

What ScalarWP built

ScalarWP built the whole process as one separate extension — deactivate it and the helpdesk returns to stock. The role split is enforced in three layers, server first: Fluent Support’s own access filter refuses a rep’s calls to close, assign or change status; its pre-update hook rejects those changes with a plain-language error; its tag hook restricts tag management to internal staff; and the extension’s own API repeats the checks on every endpoint while scoping reps to their own tickets. Only then does the browser hide the close button and the assignee picker — a hidden button is a courtesy for the rep, never the thing keeping them out, because a hidden button is one console away from being clicked.

The three-state lifecycle deliberately became a display layer rather than a data migration. The first build rewrote stored statuses to a new value — until tracing showed Fluent Support’s own stats, quick links and filters all key on the stock values, and rewriting them would have silently broken the product underneath. So In Progress is a label over the stock value, the filter merges two stock groups into one tab, and reps cannot pick Closed at all. Grouped tags took the same lesson from the other direction: reshaping Fluent Support’s own tag dropdown failed on a fact that could not change — its items carry no tag IDs — so the extension owns a dedicated modal fed by the server’s group rules, where adding a tag from a group removes its siblings.

The rest of the process lives inside Fluent Support’s own data model. The complaint number sits in ticket meta, editable by staff, captured automatically when typed into an internal note in any of four phrasings, and searchable three ways. Co-assignees are stored as Fluent Support watchers — the same pivot rows the core already maintains — with rules that add colleagues automatically when a tag is applied. The collection sign-off (“Ritirato”) is a per-user meta row: the ticket shows each responsible person’s avatar with a confirmed date or pending marker and a 2/3 counter, and removing one person’s confirmation never touches another’s.

The browser layer is built to survive the host. One debounced mutation observer runs a priority-ordered list of enhancers, each wrapped so one failure cannot take the others down, each marking what it has touched; scheduled passes catch Vue’s initial mount. Every CSS selector the layer relies on is declared in a single server-side registry, so an upstream markup change is a one-file edit. Around it: absolute Italian dates in five admin-selectable formats, a settings page with per-feature toggles and a visual tag-group editor, a documented API guarded by nonces and capability checks, 15 hooks of the extension’s own for future integrations — plus the requirements workshops, training, and a handover with 2,692 lines of documentation.

The outcome

  • Live on the client’s helpdesk and self-managed by their admin since handover.
  • Zero Fluent Support files modified and zero extra tables — everything in the helpdesk’s own meta and pivot tables, so backups, exports and upgrades already see it.
  • 5,116 lines of PHP, 3,151 of JavaScript and 892 of CSS: 9 PHP classes, 6 JS modules, 19 REST paths, 6 AJAX actions.
  • 2 roles, 9 capabilities, 3 feature toggles, 90 translatable strings — the client’s admin can reshape or switch off any part without a developer.
  • 18 Fluent Support hook points used; 15 extension hooks exposed for whatever the client integrates next.

What ScalarWP delivered

  • The two-tier role split, enforced server-side through Fluent Support’s own permission hooks.
  • The three-state lifecycle, grouped one-per-group tags, and complaint-number capture with search.
  • Primary owner plus co-assignees with tag-based auto-assignment, and the multi-party collection sign-off.
  • The re-render-proof browser layer, Italian date formatting, settings page and documented API.
  • Requirements workshops, training, eight guides plus an API reference, and handover.

Why it mattered

Forking a plugin buys a process and costs every future update; building beside it usually costs the product itself. Layering the process over Fluent Support’s own hooks and data model gave the client both: a complaints desk that matches how the company actually works, and a helpdesk that still upgrades like stock. The rules live on the server where they cannot be clicked around, the fragile browser glue is patchable in one file, and the admin has run it alone since the day of handover.

A helpdesk that almost fits your process?

Tell us the rules your team actually works by. We will layer them over the tools you already run — enforced on the server, owned by you.

← All case studies