Piešķirt personai piekļuvi jaunai lietotnei

Kad izmantot

A person needs access to an app — new to the company or new to them. Not for removing access when someone leaves — use people.offboard-employee, which consumes this register. Not for a company-wide security review of who has what — use tech.security-audit. Not for rotating the credentials of an account that already exists — use tech.password-rotation.

Pirms sāc

• The person and the purpose are named. "We might need it" is not a request.
• The access level is proposed by the requester, not assumed; admin is a separate decision.
• It is known whether the app is already used in the company (check the access register first) —

Ko izpilde pieprasa3

Ceļš8 soļi

1. S1

   Check what already existsaģents

   Read the access register for the app: is it used, on which plan, who is admin, what does it cost? Search the company mailbox for the app's domain to catch unrecorded accounts.

   Izdarīts, kad the register state for this app is written down, including "not used — nothing found".

2. S2

   Confirm the minimum accessaģents

   Map the request to the app's actual roles. Note what the requested role can do that the next-lower role cannot.

   Izdarīts, kad a one-line recommendation exists: role, plan, cost per month, why.

3. S3

   Decideīpašnieksvajag apstiprinājumu · īpašnieks

   Apstiprinājums · S3 · īpašnieks — izpilde apstājas, līdz nosaukts cilvēks ieraksta lēmumu

   Present the recommendation from S2.

   Izdarīts, kad the owner has named the person, the role and the plan (or declined, which ends the run).

4. S4

   Create the accountaģentsvajag apstiprinājumu · īpašnieksneatgriezenisks

   Apstiprinājums · S4 · īpašnieks — izpilde apstājas, līdz nosaukts cilvēks ieraksta lēmumu

   Neatgriezenisks solis · S4 — aģents to nekad nenoslēdz viens

   Sign up with the company e-mail — never a personal address. Prefer SSO through the company identity provider if the app offers it; otherwise set the initial password and store it in the company password manager (paroles), shared with the owner, not the person's private store.

   Izdarīts, kad the app shows the account with the company e-mail as its identity.

   ⛔ Never start a paid trial or plan with a personal card or a personal e-mail — the company cannot recover the account or the data later.

5. S5

   Set the role and turn on MFAaģents

   Assign exactly the role approved in S3 — not the app's default, which is often admin. Enrol MFA (authenticator app, not SMS where the app offers a choice).

   Izdarīts, kad the app's admin panel shows the role, and MFA shows as enabled for the account.

6. S6

   Verify by logging inaģents

   Log in as the new account from a clean session: sign-in works, MFA prompt appears, the role's permissions are visible (e.g. the editor sees edit buttons, the viewer does not).

   Izdarīts, kad one working login is demonstrated, not assumed.

7. S7

   Recordaģents

   Add the row to the access register: app, person, role, plan, cost per month, account owner (who approves changes), date. If the app is new to the company, add the renewal/contract date to ops.contract-renewal-watch.

   Izdarīts, kad the row exists and the register's total monthly cost is updated.

8. S8

   Hand backaģents

   Send the requester a three-line summary: how to log in (SSO or password manager entry), what they can do, who to ask for more access.

   Izdarīts, kad the person confirms they are in.

Pārbaudes — kā zinām, ka izdevās

• The account's identity is the company e-mail, read back from the app's profile page — not from memory.
• Role in the app's admin panel = the role approved in S3.
• MFA shows enabled in the app's security settings.
• The register row exists and names an owner; a run without the row is incomplete.

Ja noiet greizi

Ko atstāj katrs solis

1. S1the register state for this app is written down, including "not used — nothing found".
2. S2a one-line recommendation exists: role, plan, cost per month, why.
3. S3the owner has named the person, the role and the plan (or declined, which ends the run).
4. S4the app shows the account with the company e-mail as its identity.
5. S5the app's admin panel shows the role, and MFA shows as enabled for the account.
6. S6one working login is demonstrated, not assumed.
7. S7the row exists and the register's total monthly cost is updated.
8. S8the person confirms they are in.

Ko saglabāt

The owner's decision in S3 (who, when, what was approved) · the account's identity e-mail and role as shown by the app · a screenshot of the MFA-enabled state · the register row id · the plan price at start, so later price changes are detectable.

Kā šī procedūra uzlabojas

After every 10 runs ask: how long from ask to working login, and which step waited? Did any account later turn up without a register row, or with a role higher than approved? Did any paid plan start without an S3 approval? A new version changes the step that caused the wait or the miss, and says so in its change note.