Installing an applet is a door, not a fence — transcript

Play this as a presentation — one slide per step, with the same narration. Every word of every step is on this page.

This lesson is for whoever is asked to set up a new joiner, or to explain to an auditor what stops a person opening something they should not. In about twelve minutes you will know which parts of that story are enforced and which are tidiness, and the difference is not where most people put it.

Step 1 — Follow the chain that ends at a launchpad tile

After this step you will know where to look when somebody signs in to nothing. Access to an applet is not a setting and not a permission. It is a row: your login, one applet, one tenant. That row is written when somebody installs the applet — you for yourself from the Applet Store, or an administrator for you from Tenant Admin. What you are allowed to install comes from the catalogues your login is linked to, and what a catalogue contains is a separate set of rows an administrator maintains. So an empty launchpad is almost never a permission problem. It is a missing catalogue link or a missing install, and those are two different fixes.

Reference: Applet Store — What an installed row actually buys you

Step 2 — Know what that row really buys you

After this step you will be able to say what uninstalling achieves. It achieves more than you might expect. An applet cannot talk to the platform with your ordinary sign-in token: on start-up it trades that token for an applet token, and the server issues one only after checking that a live install row exists for your login, that applet and that tenant. With no row the exchange is refused outright and the applet never starts. So the sentence “take the applet away and they cannot use it” is true, and it is worth knowing that it is true for a real reason rather than because a tile disappeared.

Reference: Applet Store — What an installed row actually buys you

Step 3 — Know what it does not buy you

After this step you will stop using the applet list as a security boundary. Past that opening gate, the platform does not authorise by applet at all. Every server-side permission code is named for the thing it protects — a customer, a document, an export — and none of them names an applet. The applet identity carried in the token is read almost entirely to stamp the audit trail, and only two endpoints on the whole platform insist on an applet token. The practical consequence: installing fewer applets tidies what a person meets through the screens, and does not narrow what their login can do through the interface. The restriction that survives someone determined is the permission set.

Reference: Applet Store — What an installed row actually buys you

Step 4 — Watch an invitation admit somebody to a second tenant

After this step you will check a catalogue before you use it in an invitation. Granting an applet does more than write the install row: it also makes sure your login exists in that applet’s tenant. And the tenant each grant lands in is taken from the catalogue’s own membership row, not from the tenant you thought you were inviting into. So one catalogue holding rows that point at two companies’ tenants will, from a single invitation, admit the new joiner to both. Nothing on the invitation screen shows you that. Open the catalogue, read the tenant on each row, and keep one catalogue per tenant unless you have a reason not to.

Reference: Applet Store — What an installed row actually buys you

Step 5 — Understand why “install everything” is a fair option

After this step you will make the right call on the invitation toggle. There is a setting that installs every applet in the catalogues you pick when you invite somebody. Read as install everything, it sounds reckless. Read accurately, it is bounded: it refuses to run at all unless you have chosen at least one catalogue, and it installs that catalogue’s contents and nothing else. So the risk is not the toggle. The risk is a catalogue nobody has looked inside, which is exactly the thing the mandatory picker is there to make you look at. Compose the catalogue deliberately and the convenience is a fair one.

Reference: Employee Maintenance

Step 6 — Put the boundary where the boundary is

After this step you will have a defensible shape. Applet installs decide what a person meets; permission sets decide what their login may do; and company, branch and location targets narrow some of that further, on documents, which is the subject of the next lesson. Catalogues reach down to a tenant and stop there — there is no such thing as a catalogue for one branch, whatever the field names near it might suggest. So when somebody asks you to keep two parts of a group apart, the honest answers are separate tenants, or permission sets that differ. Not a shorter applet list.

Reference: Tenant Admin Applet — What the target actually does once you have set it

How the steps fit together

    flowchart TD
  s1["Step 1 — Follow the chain that ends at a launchpad tile"]
  s2["Step 2 — Know what that row really buys you"]
  s3["Step 3 — Know what it does not buy you"]
  s4["Step 4 — Watch an invitation admit somebody to a second tenant"]
  s5["Step 5 — Understand why 'install everything' is a fair option"]
  s6["Step 6 — Put the boundary where the boundary is"]
  s1 --> s2
  s2 --> s3
  s3 --> s4
  s4 --> s5
  s5 --> s6
  

Check yourself

Three to five questions on what you just heard. Every correct answer links to the page that makes it correct, so you can check the source, not just the mark.

Next: A target restricts documents, and not your customer list · Back to the series · Play this as a presentation