Skip to content

Custom Software

Admin systems: change how the software behaves, safely

Every custom system has settings that should change without a developer: review limits, quiet hours, what each town's permit packet needs, who can do what. An admin system is where they're changed. A good one shows what a change will affect before it's saved, asks a second person when it matters, keeps a history and makes undoing a change one step.
Discuss your systemSee what it manages ↓
Settingsquotes reviewed by the ownerover $5,000over $7,500office manager · editingquiet hours8 pm – 8 amEastside furnace packet4 itemscoordinator role6 permissionsoffice manager · $5,000 → $7,500 · approved by owner · Oct 27Undobefore you save2 open quotes would skip reviewQ-418 · $6,200Q-421 · $5,900needs the owner's approvalapproved by owner

What an admin system manages

Six areas. Most systems need some of each.
Recordsmerge a duplicate customeroffice manager
Settingsquiet hours, review limitsoffice manager; the owner approves large ones
Ruleswhat Eastside's permit packet needscoordinator
Permissionswhat a coordinator can doowner
Exceptionsa stuck sync, a failed paymentwhoever is on duty
Operationsovernight jobs and when they last rantechnical lead

Five safeguards on every change

Admin screens are used rarely, by people in a hurry. The safeguards are the design.

  1. 01

    Preview

    See what it will affect

    Before saving, the screen shows which live records the change touches: these two quotes, those three jobs.

  2. 02

    Second approval

    For changes that matter

    Money limits, permissions and deletions wait for a second person, named in advance.

  3. 03

    History

    Who, when, old value, new value

    Every change is recorded, so “who changed this?” is answered from the record.

  4. 04

    Undo

    One step back

    A change can be reversed in one step, and the reversal is recorded too.

  5. 05

    Limits by role

    Settings sit with their owners

    The coordinator edits packet rules; only the owner edits permissions.

One admin task, step by step

Merging two records for the same customer, with a person deciding anything the software can't.

Duplicate customer · C-0731 and C-0918

  1. Possible duplicate found

    same name and phone, J.H.

    done

  2. Fields compared

    phone matches; addresses differ

    done

  3. Office manager chose the address

    the newer one, confirmed by phone

    done

  4. Records merged

    jobs, invoices and messages moved to C-0731

    done

  5. History kept

    C-0918 can be split back out

    done

One customer record, every job and invoice on it, and a record of how it was merged.

What admin systems hand off

In

Settings and rules
limits, packets, quiet hours
Records and exceptions
duplicates, stuck items
Roles
who may change what
Admin system
preview → approve → apply

Out

Behaviour
as configured, everywhere
History
every change, who and when
Undo
one step back

Worth building when your rules change more often than your code

Good fit

  • Settings or rules change monthly, and today a developer changes them.
  • Several people need to change different things.
  • Someone needs to know who changed what, and when.

Not the right fit

  • Settings change once a year. A developer can do it.
  • The product you use has its own admin screens that work.

Where admin systems are used

Next to admin systems

Questions about admin systems

Isn't this just a settings page?

The page is the easy part. The work is knowing what each setting affects, who may change it and how it's undone.

Can a bad change break things?

Changes are checked before they're saved, previewed against live records and undone in one step. Risky ones wait for a second person.

Who should have admin access?

As few people as possible, each for the areas they own. Every change is recorded either way.

Is it a separate system?

Usually not. The admin area lives inside the application, next to what it controls.