Skip to content

Infrastructure & Integrations

Identity and access: who is this, which company, and what may they do

Software that several companies share has to keep each company's records apart, every time. Software one business uses still has an office manager, technicians, a bookkeeper and a few connected systems, each needing different access. Hiding a button isn't access control. We check every request on the server: who is asking, which company it's for and whether their role allows it.
Talk through who needs accessSee roles written down ↓
whocompanymayManager · Company Aopen request 4BallowedContractor · Company Aopen a Company B requestdenied · other companyContractor · Company Achange billing detailsdenied · role can'tAccounting key · Company Aread closed requestsallowed · read onlySupport · the product's staffdelete Company B's dataheld · second person approves

Roles, written down

Each role gets the access its work needs, and nothing it doesn't. The list is short on purpose.
Managersee and assign every request in their company, invite peoplesee other companies, change the product's settings
Contractorsee requests assigned to them, add notes and photossee billing, see unassigned requests
Tenantreport a problem, follow their own requestsee anyone else's
Accounting keyread closed requests for its companychange anything
Product supportsee a company's data when the company allows itdelete data without a second person

What identity and access covers

  1. 01

    Sign-in

    One person, one sign-in

    A link by email, a password or the company's own sign-in, with a second step for anyone who can change important things.

  2. 02

    Roles

    Written down, checked on the server

    What each role can see and do, enforced on every request.

  3. 03

    Company boundaries

    Each company's records kept apart

    Designed in from the first table, because adding it later means touching everything.

  4. 04

    Keys for connected systems

    Their own identity, limited access

    An accounting export gets a key that can only read what it needs, and can be replaced without disturbing anyone.

  5. 05

    Risky actions

    A second person approves

    Deleting a company's data or changing who's in charge waits for someone else to agree.

  6. 06

    A record of who did what

    Kept, not reconstructed

    Sign-ins, role changes and privileged actions, each with who, when and why.

Three moments that test it

Access isn't set once. These are the days it matters.

Company A · contractor's last day

  1. Removed by the manager

    one action, in the company's settings

    done

  2. Signed out everywhere

    phone and laptop, at once

    done

  3. Assigned requests

    returned to the manager to reassign

    done

  4. Their notes and photos

    kept on the requests, credited to them

    done

  5. Recorded

    who removed them, and when

    done

No shared password to change, and nothing they did is lost.

Added later, or designed in

Logins added later

  1. 01One shared login per office
  2. 02Buttons hidden instead of requests checked
  3. 03Company boundaries added after the first customer
  4. 04Connected systems using a person's account

Nobody can say who did what, or prove one company can't see another's records.

Access designed in

  1. 01A sign-in per person
  2. 02Every request checked on the server
  3. 03Company boundaries in the first table
  4. 04Each connected system with its own limited key

Every action has a name on it, and every boundary is checked.

Where access is decided

In

People
sign-in, second step
Connected systems
their own keys
Roles and companies
written down
Access
who · company · may

Out

Decisions
allowed, denied, held
Record
who did what, when
Sessions
ended when access ends

Worth designing early when more than one company or role is involved

Good fit

  • Several companies will share the same software.
  • Staff, customers and contractors need different access.
  • You need to show who saw or changed what.

Not the right fit

  • A tool one person uses. A simple sign-in is enough.
  • Access is fine; the problem is what people see. That's the portal or the screen design.

Where this capability is used

Next to identity and access

Questions about identity and access

Can our staff sign in with the accounts they already use at work?

Usually, yes. If your company already has its own sign-in, the software can use it, so people don't have another password and leaving the company ends their access everywhere.

Do you build sign-in from scratch?

No. Passwords, sign-in links and second steps come from a proven sign-in service. What we build is the part that's specific to you: roles, company boundaries and the rules for risky actions.

How do you keep one company from seeing another's data?

Every record carries its company, and every request is checked against it on the server and in the database itself, so a mistake in one screen can't show another company's records.

Are you a security consultancy?

No. We build access control properly as part of the software. Audits, penetration tests and certifications are done by specialists, and we work alongside them when you need them.