Managing QR Codes Across a Team: Roles and Permissions

On a Tuesday afternoon a marketing coordinator opened the account, changed a destination to test a landing page variant, and got pulled into a meeting. The code she edited was printed on sixty thousand pieces of direct mail that had landed the week before. The variant page was half-built. Nine days went by before anyone connected the drop in responses to the edit, because the person watching the report and the person with edit access were different people who never spoke.

Nothing was malicious and nothing was technically broken. One text field changed, and the behavior of sixty thousand physical objects changed with it.

Editing a live destination is a production change

With static print, a mistake is expensive and loud. Someone has to reprint, someone signs the invoice, and everybody finds out.

With a routed code, the identical mistake is a text field and a save button. No build, no review, no deploy log, no visible artifact. The reach is every printed copy in circulation and it takes effect immediately, which is the tradeoff that comes with dynamic codes and rarely gets discussed when the decision is made.

Treat that field the way you treat pushing to a live site. Not because the tool is dangerous, but because the exposure is comparable while the friction is not.

Roles worth separating

Four capabilities, which most teams collapse into one.

Create. Making new codes for new work. This is the broadest right and the least dangerous one. Hand it to anyone who needs it, including agencies and event staff, scoped to their own folder.

Edit live destinations. The narrow one. Named individuals, small group, no shared logins.

View analytics and reports. This should be the widest right of all, and it is the one most often bundled with everything else. The standard failure is granting a whole team administrative access so they can watch scan counts. Reading a scan report should never require the ability to change what the codes point at.

Administer. Billing, users, custom domains, deletion. Smallest group, and never fewer than two people, so that a vacation is not an outage.

Deletion deserves its own line. For a routed code, deleting the record breaks every printed copy at once and is usually irreversible. If your platform can separate delete from edit, separate them.

If a tool cannot distinguish these capabilities at all, that is a real limit on how many people can safely touch it, and it belongs on the evaluation list alongside the usual criteria when comparing platforms.

An approval step before a printed code changes

The step does not have to be heavy. It has to exist.

A change request records five things: the code and its reference, the current destination, the proposed destination, the reason, and where the code is physically printed and in what quantity. That last item is what makes the risk legible. "This is on sixty thousand mailers" ends a lot of casual edits before they start.

Then a second person confirms the new URL loads, is the intended page, and behaves on a phone rather than only on a desktop.

Set a threshold so the process survives contact with real work. Above a printed volume you choose, or on any material you cannot recall, require the second pair of eyes. Below it, keep review optional. A process that applies to every trivial change gets routed around within a month.

Two habits that cost nothing: no destination edits late on a Friday, and rescan a physical copy after every change rather than trusting the dashboard preview.

Every code needs a named owner

Not a department. A person, recorded in the code's own record rather than in somebody's memory.

The owner is who gets asked when a destination breaks, who approves changes, and who is accountable for retiring it. "Marketing owns it" means nobody owns it, and the test is easy: pick a code at random and time how long it takes to find someone willing to make a decision about it.

Ownership also gives the reporting a purpose. A code with an owner gets looked at. A code without one is a line in a dashboard nobody reads, which is how codes end up pointing at dead pages for a year.

Offboarding is where codes go orphaned

The pattern repeats across organizations and is entirely predictable.

• Codes created under a personal account instead of the company account.
• Vendor accounts registered to an individual's email, so a password reset goes to a mailbox that no longer exists.
• A payment method on a personal card. The card expires after the person leaves, the account lapses, and every routed code stops resolving. The outcome matches what happens when a provider shuts down, except that you did it to yourself.
• Destinations hosted on a service only that person could log into.
• Codes whose named owner is the one walking out the door.

Put four items on the offboarding checklist. Reassign every code they own to a named replacement. Confirm no account or domain is registered to their address. Confirm no billing runs through their card. Confirm no destination depends on their personal login. Do all of it before the last day, while they can still answer questions.

While you are in there, check what the vendor actually promises if an account goes quiet. Services advertising codes with no expiration are making a claim about their own continued existence, and that claim is worth reading rather than assuming.

Log the changes, then actually read the log

Every destination edit should record who, when, from what, and to what. Most platforms keep this. Almost nobody opens it.

Review it monthly against your change requests. You are looking for edits with no matching request, edits from accounts that should not have edit rights, and edits to codes nobody has thought about in a year. A compromised account on a QR platform does not look like an attack. It looks like a destination quietly pointing somewhere new, which makes a legitimate printed code behave exactly like the fake codes your customers are warned about.

Shared logins defeat all of this. You cannot attribute a change, you cannot revoke one person's access, and you cannot tell a mistake from a breach.

Start with what is already printed

Export the list of routed codes currently on physical material and sort it by printed quantity. Take the top ten and answer two questions for each: who can change this destination right now, and who is accountable if it breaks.

If either answer is "everyone" or "not sure", fix those ten this week, before writing any policy at all.