User Roles and Permissions in Traffic Control Software: Who Should Be Able to Do What

On the first day with new software, most companies give everyone the same access because it is quicker. A year later a crew lead has deleted a job by accident, a seasonal hire can see every customer's rates, and nobody can say who changed the hours on last Tuesday's ticket.

Roles and permissions are how you prevent that. This guide covers the roles a traffic control or barricade company usually needs, the actions that deserve extra protection, and the questions to ask a vendor.

The idea in one sentence

Give each person the access their job needs and no more.

Security people call this least privilege. The NIST glossary defines it as a principle that a system should restrict the access privileges of users to the minimum necessary to accomplish assigned tasks. It is usually discussed as a defense against attackers. In a small company its everyday value is simpler: fewer mistakes, and a clear answer when something does go wrong.

The roles most companies need

Job titles vary. The underlying jobs are consistent.

Owner or administrator. Full access, including settings, users, integrations and billing. Keep this group small. Two or three people is typical.

Dispatcher. Builds the schedule, assigns crews and equipment, creates and sends quotes, and manages customer records. Dispatchers need wide access to operations. They generally do not need to refund a payment or change who has access to what.

Field crew. Flaggers, drivers and crew leads. They need to see their own assignments, clock in and out, complete the daily ticket, collect a signature and upload photos. They should not see other customers' pricing or company financials.

Accountant or bookkeeper. Sends invoices, records payments, runs financial reports and exports to the accounting system. Needs to read jobs and tickets, not to edit the schedule.

Viewer. Read-only. Useful for an owner's adviser, a safety manager who reviews records, or a manager at a second yard.

Yard or inventory staff. In companies with significant rental fleets, someone who can move stock, receive purchase orders and record damaged devices without touching customers or invoices. See yard organization for traffic control companies.

A useful test for any role: could a new hire in this job do a full day's work with it, and could they do anything that would cost you money if done by mistake? Our post on who does what in a traffic control company maps the jobs themselves.

The actions worth protecting

Most of what people do in dispatch software is low risk. A handful of actions are not, and those are where permissions earn their keep.

Sending invoices and recording payments. A dispatcher drafting an invoice from an accepted quote is efficient. Sending it to the customer and collecting money is a billing decision that someone accountable for billing should make. Separating "create" from "send" gives you a review step for free.

Refunds and credits. Restrict to very few people.

Editing time after the period is closed. Payroll disputes and wage claims turn on time records. Once a pay period is approved, changes should need an administrator and leave a trace. See GPS time clock for traffic control crews.

Changing a signed ticket. A daily ticket signed by the customer's representative is evidence. If it has to be corrected, the correction should be visible as a correction. See electronic signatures on traffic control daily tickets.

Adjusting inventory. Write-offs and count adjustments are how device losses get hidden, on purpose or by carelessness. Limit who can make them.

Changing rates and customer terms. A rate sheet is a contract term. Dispatchers apply it; they should not be able to rewrite it quietly.

Approving purchase orders and receiving goods. Different people should order, receive and pay where the company is large enough to allow it. See purchase orders and vendor management.

Deleting anything. Deletion should be rare, restricted and logged. Archiving is safer.

Managing users, roles and integrations. Whoever can change permissions can give themselves all of them.

One login per person

Shared logins are the most common access mistake in this trade. "The crew tablet" with one username defeats the purpose of half the system.

If three flaggers clock in under one account, the time record cannot say which of them was on site. If a ticket is completed under a shared login, you cannot say who collected the signature. If something is deleted, the log names a tablet.

Individual accounts fix that, and they make leaving clean: when a seasonal worker's last shift ends, you disable one account and nothing else changes.

The obstacle is usually price. Software billed at a full rate for every user makes forty seasonal logins expensive, so companies share accounts to save money and lose the record. That is a pricing problem, not a security one. When you compare vendors, price the plan with a login for every field worker, not just the office. Our comparison of per-user vs flat-tier pricing explains the arithmetic.

Sign-in security

Permissions limit what an account can do. They do not help if someone else is using the account.

Three basics apply to any system holding customer and payroll data:

• Multifactor authentication for administrators and anyone handling money. CISA describes multifactor authentication as a layered approach to securing accounts, and notes that users who enable it are significantly less likely to be compromised, because a stolen password alone is not enough. Ask each vendor whether it is available and whether you can require it for certain roles.
• Remove access the day someone leaves. Seasonal turnover makes this a weekly task in summer.
• No shared administrator account. Each administrator signs in as themselves.

The audit log

Permissions prevent some problems. The audit log explains the rest.

A good log records every change of state: who created, edited, sent, approved or deleted a record, with the time and the before and after values. The questions it answers are routine in this business:

• Who changed the hours on this ticket, and when?
• Was the quote edited after the customer accepted it?
• Who marked these forty barricades as returned?
• Who moved the crew off this job on Thursday night?

Without a log, each of those is an argument between two people's memories. With one, it is a lookup. That matters most when a customer disputes a bill; see preventing daily ticket disputes.

When evaluating software, ask to see the log for a single job from quote to invoice. If the vendor cannot show one, assume there is not much there.

Multiple yards

A company with more than one location has a second dimension: not just what a person can do, but where. A dispatcher in one city may need to see only that yard's crews and stock, while the owner sees everything. Ask whether access can be limited by location, and whether inventory transfers between yards are recorded with both ends. See traffic control software for multi-yard operations.

Setting it up without overthinking it

1. List the people, not the titles. Write down what each person actually does in a week.
2. Start from the preset roles. Most systems ship with sensible defaults. Change them only where your company differs.
3. Give field staff the narrowest role that lets them finish a shift. Test it with one crew lead before rolling it out.
4. Decide who can do each protected action. Name them.
5. Review twice a year. Once before the season when you add people, once after when you remove them.
6. When someone hits a wall, fix the role, not the person. If a dispatcher keeps borrowing an administrator's login to do a routine task, the role is wrong.

Rolling permissions out alongside the rest of a new system is covered in rolling out traffic control software to your crews.

Questions to ask a vendor

• What roles come built in, and can we create our own?
• Are permissions set by action, such as create, send and delete, or only by screen?
• Can field staff be limited to their own jobs and their own time?
• Is there an audit log of every change, and can we read and export it?
• Can pay periods and signed tickets be locked?
• Is multifactor authentication available, and can we require it by role?
• Does adding users change the price?
• When we disable a user, what happens to the records they created?

More vendor questions are in our software demo checklist and the dispatch software buyer's guide.

How Traffic OS handles it

Traffic OS ships with preset roles for owner, admin, dispatcher, driver, accountant and viewer. Permissions are set per action, so a dispatcher can turn an accepted quote into a draft invoice while sending it stays with the accountant or an admin. Pay periods can be locked, and an audit log records every change of state. When a user lacks permission for an action, the screen tells them which roles have it, so they know who to ask.

The full list is on the features page. Pricing is by flat monthly tier. Each tier includes a set number of admin and driver seats, and extra seats are a published flat rate, so you can work out the cost of giving every flagger a personal login before you sign.

To see the roles applied to your own org chart, book a walkthrough.