Broker guides

Freight Broker TMS User Permissions: A 10-Scenario Role Access Test

freight broker TMS user permissions

A role named “dispatcher” tells you little about what a user can actually see or change. The reliable way to evaluate permissions is to test actions with controlled accounts.

A dispatcher may need to update an appointment without seeing every customer’s margin. A billing reviewer may need documents and charges without being able to reassign a carrier.

Use this 10-scenario test during a TMS trial, implementation, or access review. With synthetic or properly authorized data, record what each user can view, create, edit, approve, export, and administer.

> Public-fact and product boundary: NIST and CISA sources below provide general security and software-procurement guidance. Current 49 CFR 371.3 defines records a broker must keep; it does not prescribe TMS roles. None of these sources evaluates ServeOps. This guide does not claim that ServeOps provides configurable roles, MFA, SSO, audit logs, branch restrictions, field-level permissions, approval controls, exports, session revocation, or any other access-control function.

<!-- Visual placement: /content/broker-guides/freight-broker-tms-user-permissions-role-access-test/01-role-action-permission-grid.svg -->

Start with an action grid, not job titles

NIST defines least privilege as restricting access to the minimum necessary to accomplish assigned tasks. That principle is more useful when translated into specific brokerage actions.

Build a grid with roles down the left and actions across the top. Your roles might include:

  • dispatcher or carrier sales;
  • customer sales or account manager;
  • billing or accounting reviewer;
  • operations supervisor; and
  • system administrator.

Your action columns should include customer records, carrier records, rates and margin, load creation, carrier assignment, status changes, documents, customer charges, carrier payables, approvals, exports, reports, user administration, and configuration.

For every intersection, choose allow, deny, allow with approval, or not applicable. “Limited access” is not testable.

A two-person brokerage may combine roles that a larger operation separates. Make the decision explicit and verify the software behavior.

Prepare five controlled test accounts

Create one account for each representative role if the trial permits it. Never borrow an employee’s credentials. Use a synthetic customer, carrier, three loads, two documents, one accessorial, and one restricted financial field.

Before testing, record:

  1. the expected permission;
  2. the account and role used;
  3. the exact action attempted;
  4. the observed result;
  5. the evidence captured; and
  6. the owner of any gap or configuration change.

Evidence may be a blocked action, successful edit, export, approval history, timestamp, or written vendor clarification. Avoid private production data in screenshots.

The 10-scenario freight broker TMS permission test

1. Dispatcher: complete ordinary load work

With the dispatcher account, open an assigned synthetic load, update an appointment, add an internal note, attach a harmless test document, and record a status change.

Pass condition: intended work succeeds without temporary administrator access. Record any ability to change charges, payables, margin, or company settings as a separate decision.

2. Dispatcher: attempt a denied financial action

Try to edit the customer sell amount, carrier buy amount, approved accessorial, or other financial field your matrix reserves for a different role.

Pass condition: the action is unavailable or rejected clearly. If only a written policy blocks it, score the technical permission as allowed and document the procedure separately.

3. Billing reviewer: retrieve the invoice evidence

Use the billing account to find the rate confirmation, proof of delivery, approved accessorial support, customer instructions, charges, and carrier payable for a completed synthetic load.

Pass condition: the reviewer reaches approved billing evidence but cannot perform unrelated dispatch or administrative actions. Record any routine elevated-access dependency.

4. Supervisor: approve an exception

Create an accessorial or other synthetic exception that requires supervisor review under your policy. Attempt the approval first as a dispatcher, then as the designated supervisor.

Pass condition: the correct role decides, the other cannot silently self-approve, and the record identifies the decision, actor, and time when required. This is an editorial test, not law.

5. Administrator: manage identity without doing load work

Use the administrator account to create, change, or deactivate a test user if those controls are available. Then check whether the administrator can also quote, assign a carrier, alter charges, or approve exceptions.

Pass condition: observed access matches the matrix. Broad administrator access may be accepted, but it should be tightly assigned, protected, and reviewed.

6. Customer or branch boundary: look sideways

Assign one test account to Customer A or Branch A, then try to search for, open, report on, and export Customer B or Branch B records.

Pass condition: the promised boundary holds across screens, search, reports, notifications, and exports. A hidden menu is not a boundary if data remains reachable elsewhere.

7. Export: inspect what leaves the system

Run every export available to a non-administrator test role. Open the file outside the TMS and inspect fields, rows, documents, hidden columns, and cross-customer data.

Pass condition: the export follows approved scope and exposes no unauthorized fields. Verify scheduled reports, emailed reports, APIs, and integrations separately.

8. Authentication and recovery: test the account boundary

Ask the vendor to demonstrate the available MFA, SSO, password-reset, recovery, and session controls for the exact plan under consideration. CISA recommends MFA wherever possible, starting with administrative accounts and people handling sensitive data, and advises using the strongest available method.

Pass condition: required authentication and recovery behavior is demonstrated. Do not infer phishing resistance, session termination, or plan availability from “secure.”

9. Change history: reconstruct one controlled event

Change a pickup time, charge, assignment, and permission using approved test accounts. Then ask an authorized reviewer to reconstruct what changed, who acted, and when.

Pass condition: evidence meets the brokerage’s written accountability requirement. CISA’s Secure by Demand Guide suggests asking whether logging and SSO are baseline features and whether logs cover identity, configuration, and relevant data activity. That is buyer guidance, not product proof.

10. Revocation: remove access without stranding work

Assign a synthetic open load to a test user, sign in, then run the authorized deactivation or role-removal process. Check the old session, a new sign-in attempt, the open load’s owner, scheduled outputs, and any linked access path the test covered.

Pass condition: access and operational ownership match the approved result. Use the separate offboarding guide for the full people, communication, seat, integration, and work-transfer process.

<!-- Visual placement: /content/broker-guides/freight-broker-tms-user-permissions-role-access-test/02-ten-scenario-access-scorecard.svg -->

Score permissions by control surface

Give each scenario one result:

  • Pass: observed behavior matches the written matrix with acceptable evidence.
  • Conditional: a documented configuration, separate product, vendor action, or procedural control is required.
  • Fail: the user can perform a prohibited action, cannot perform required work, or the scope cannot be verified.
  • Not tested: no evidence was produced.

Do not average the results into one reassuring percentage. Track six control surfaces separately: interface, search, reports, exports, integrations, and administration. A field hidden on a load screen can still appear in a spreadsheet or report.

Record plan, add-on, implementation, seat, configuration, and support dependencies. A control may exist but remain unavailable within the selected package or timeline.

Protect the broker record while limiting access

Current 49 CFR 371.3 requires a broker to keep a record of each transaction, lists six items the record must show, sets a three-year retention period, and provides review rights to each party to the brokered transaction.

The rule does not say that a particular employee must see every record, and it does not certify a role design. Test both goals: users receive only the access approved for their work, while authorized staff can still retrieve the transaction record under the brokerage’s policy. Have qualified advisers decide legal, contractual, privacy, employment, and security requirements for your organization.

Public facts versus verified ServeOps functionality

Public facts and guidance: NIST defines least privilege; CISA recommends MFA and provides buyer questions about authentication and logging; 49 CFR 371.3 defines broker transaction-record obligations. These sources do not evaluate ServeOps.

Original editorial method: the action grid, five-account setup, 10 scenarios, pass/conditional/fail/not-tested score, and six-surface review are ServeOps editorial tools. They are not laws, security guarantees, or universal role designs.

Verified ServeOps offer only: 60-day free trial; card collected upfront; no charge for 60 days; cancel anytime; then $49 per seat/month or $490 per seat/year.

No ServeOps permissions, authentication, logging, export, record-retention, approval, branch, billing, or security functionality is claimed here.

If ServeOps is on your shortlist, start a 60-day trial and run the same controlled role test you use for every vendor. Make the decision from observed evidence and the complete checkout terms.

Sources