UK Sign Maker Scales Rollouts with Quickbase + SharePoint

See how a ~80-person UK signage manufacturer used Quickbase and SharePoint to launch rollout programmes from a template and track every site in one dashboard.

Oct 9, 2026

UK Sign Maker Scales Rollouts with Quickbase + SharePoint

💡

TL;DR: A ~80-person UK signage manufacturer was running each multi-site brand rollout in its own hand-built Quickbase app, with files scattered and no single view across programmes. A Connex consultant turned that into a repeatable system: a template app that launches new programmes, a central dashboard that syncs from every project app, SharePoint folders that build themselves, and one notification pipeline each for UK and international work. Two and a half years and 50+ build sessions later, the system is the backbone of how the company runs rollouts, and a second internal team asked to use it the same way.

Manufacturing floor: the kind of multi-site rollout work this Quickbase and SharePoint system tracks. Photo by Cemrecan Yurtman on Unsplash

The Situation

The company is a ~80-person signage and brand-implementation manufacturer headquartered in the UK. It designs, builds and installs signage for national and international brands, usually as rollout programmes: one client, dozens or hundreds of sites, each moving from survey to design to manufacture to installation.

Location matters here. The business runs both UK and international installations, and those follow different rules, teams and notification paths. Any system had to know which was which.

The stack before Connex: Quickbase as the operational database, SharePoint for project files, Microsoft 365 for email, and a field app for installation crews. The head of engineering owned the Quickbase side and was learning the platform himself.

The Problem

Every new client programme meant a new Quickbase app, built more or less by hand. Each app had its own fields, its own file handling and its own notifications. That worked for one or two programmes. It broke down as the number grew.

The brief the head of engineering wrote at the start was clear about what was missing:

A template project app where new sites could be added and managed.
File uploads that land in SharePoint, with Quickbase holding a link to the right folder.
A button that creates a new programme from the template, instead of copying an app by hand.
A master reporting app that pulls in data from every project.

Underneath that was the familiar problem: nothing gave leadership one view. Status lived in separate apps, files lived wherever someone had saved them, and "how many jobs are in design right now?" meant opening several systems and counting.

What They'd Already Tried

The team had already built and launched at least one live programme app on their own, and the head of engineering had been "dabbling in Quickbase to learn it" for himself. The individual apps worked. What they couldn't get to on their own was the layer above them: a launcher, a cross-app sync and a file system that stayed consistent as programmes multiplied.

The platform also has limits that only show up at scale. Pipelines have a step limit (26 steps per pipeline, per Quickbase's published limits as of October 2026). Multi-factor authentication blocks some automated setup steps. Bulk edits don't always fire the triggers you expect.

What We Built with Quickbase and SharePoint

1. A template app and a programme launcher

New programmes are now created from a template app by a pipeline, not copied by hand. Each new app registers itself with the central dashboard. Where multi-factor authentication stopped the pipeline from assigning user tokens automatically, the consultant made that a documented manual step, with the instructions stored in the app itself, so launches stay repeatable without hiding the exception.

2. A central dashboard that syncs from every project app

Field IDs differ from app to app, so the sync matches fields by name and by ID through a field-management table. Each field has a checkbox to turn syncing on or off. Pushing very wide records through pipelines gets slow and brittle, so the dashboard caps the selection below 100 and tells the user when the limit is reached. A scheduled weekly sync keeps everything aligned, and a manual bulk-sync button covers the gaps.

One of those gaps came straight from the client: "We're having a few issues with the sync from the project apps to the general reporting app when a project manager edits site statuses via the 'edit all sites' button." Bulk edits weren't firing the pipeline on status changes. The fix was a webhook-driven bulk update plus a manual trigger on the dashboard, so bulk changes still reach the reporting layer.

3. SharePoint folders that build and repair themselves

Each site gets a standard SharePoint structure: planning, quotation, installation, brand book and engineering drawings. Folder links are written back to the Quickbase record. If a file is uploaded and the target folder is missing, the pipeline creates the folder and subfolder first and then files it. A weekend job reprocesses any files that got stuck in processing, and a link-check pipeline refills empty folder-link fields.

External partners only see what they should. Folder permissions are set per user, and a per-record setting hides selected sites from partner roles in Quickbase.

4. One notification pipeline for UK work, one for international

Notifications started as individual webhooks inside each app. That led to duplicates firing seconds apart. The consultant first added a queue in Power Automate to drop duplicates, then consolidated everything: each app now forwards changes to a single domestic pipeline or a single international pipeline. Those pipelines compare the previous and current values of a record and only notify when a rule is actually met, such as a status change or a checkbox going from false to true. Notifications can go to everyone in a role, not just named users.

5. Dashboards that answer the operational questions

The client specified the charts precisely. One example: the number of jobs currently in design, counted from sites that aren't completed, on hold or out of scope, have a date into design and a drawing due date. Lead times are measured in working days, excluding weekends and holidays. The dashboards now show jobs in design, production and installation scheduled versus completed, lead-time buckets with overdue jobs shown first, and weekly audit, survey and brand-book progress.

6. Hardening as the system grew

Later work added a deletion pipeline that cleans up a site across the dashboard and SharePoint, fixed two pipelines racing to create the same folder overnight, added a short-turnaround alert, and moved file uploads from webhooks to direct pipeline triggers.

The Results

The client never gave us task-level volumes or time-per-task figures, so we aren't putting an hours-saved or dollar estimate on this one. What we can point to is real:

New programmes launch from a template instead of being rebuilt by hand. Every programme follows the same fields, folders and statuses.
Leadership gets one cross-programme dashboard instead of opening app after app. Site statuses were cut to seven: Enquiry, Ordered, In Design, In Manufacture, Completed, On Hold and Out of Scope.
Files land in the right SharePoint folder by default, and missing folders are created on the fly instead of failing the upload.
UK and international notifications route through two pipelines instead of a webhook per app, with change detection built in to cut duplicate alerts.
The engagement has run for about two and a half years and more than 50 logged working sessions, with the client renewing time in 10-hour blocks.

When the wider team moved onto the platform in early 2025, launch brought the usual wave of bugs and requests. Both sides moved to a single tracker with comments per item and a fixed weekly block of build time, and the system kept growing from there.

Client Voice

The strongest signal came from a different part of the business. A newly hired operations leader on the North American side wrote in to ask for help with project management, saying:

"Given the work Connex has done with [our head of engineering], we thought it worth asking ... as we are keen to leverage QB in similar ways." (Head of operations, North America)

When another team asks to copy the setup, it's working.

FAQ

Will this work if our Quickbase apps were all built differently?

Yes. The sync matches fields by name as well as by ID, through a mapping table, because no two of this client's apps used the same field IDs. You don't have to rebuild existing apps before connecting them to a central dashboard.

Does Quickbase have to store the files?

No. Here, files live in SharePoint in a standard folder structure, and Quickbase stores the link. The pipeline creates any missing folders and sets per-user permissions for external partners.

What about Quickbase's limits on pipelines and synced fields?

They're real, and we designed around them: under 100 synced fields with a clear message at the limit, separate pipelines where step limits bite, a documented manual step where multi-factor authentication blocks automation, and scheduled jobs to catch anything a trigger misses.

Running Programmes Out of One-Off Apps?

If every new client, site or project at your company means building another app or spreadsheet by hand, and no one can see across them, that's the problem we fix. Book a free call with a Connex consultant and we'll map out what a template-and-dashboard setup would look like for your Quickbase apps.

Costume tracking in Zapier Tables (no more paper)