← Back to dashboard

What the customer sees

Audience: customer · Profile: pov · Read this when: you have been given a login or a link to a POV environment, or you are the one handing them out.

Part of A POV Instance. The use-case checklist, PRA vendor access, the ephemeral accessor login, and the share link.

Use cases, per POV

Use cases in the nav, or POV page → a POV's name → Use cases. Both lead to the same checklist; the first picks the POV for you, the second is where you act on it.

The in-app Use cases catalog is instance-wide: it asks feature_flags whether a demo can run here, and on a POV instance the answer for most of it is "no, this profile masks that". Correct, and useless in front of a customer — it was twenty-six greyed-out cards saying so. So on a POV instance that page leads with a POV: pick one from the selector and you get its checklist, asking a different question — can I run this on THIS POV? — whose answer comes from the three tenant columns on the row, which is exactly where a Password-Safe-only evaluation differs from an all-three one.

The instance-wide catalog is not on that page at all on a POV instance. It answers a question about the instance — "can this instance run it?" — which a POV page has no use for, and the twenty-six grey cards it produced here were the wall the lead exists to replace; leaving them collapsed underneath left them one find-in-page away. An estate instance opens exactly as it always did.

That page reads. Each row shows a ✓ or a – and the word for it, not a control: ticking a card off lives on the POV's own page, which is where every other action on that POV lives too, and a checkbox on a page that records nothing would be worse than no checkbox.

The page shows the cards this POV can run. The product mix decides what each one says:

A card for a product this POV has no tenant for is not shown, on your page or the customer's, and a product with nothing else in it gets no heading either — a POV scoped to Password Safe shows the Password Safe and environment cards, and that is the whole page. Which products the evaluation includes is on the Overview tab, next to the tenants that decide it; add a tenant there and that product's cards appear, with nothing to re-enable.

Those cards are not gone, only undrawn: nothing subtracts them from the catalog and no route is closed. This is not the same state as an estate-only feature being masked on this instance — nothing is wrong, and nobody needs to turn anything on from Settings. Earlier builds did list them on your page, in a dashed not part of this POV section, which on a one-product evaluation put two products' worth of rows you could not act on above the handful you were there for.

A card that names two products needs both. On a POV missing one of them it is out of scope rather than "needs wiring" — "run the wire-up" would send you to a button that skips the half you came for.

Ticking them off

Each card has a checkbox and a Skip control, and on your page clicking anywhere on the row that is not a link or a button ticks it too. The count rides on the row in the POV list. The customer's version of the same row has a checkbox, a Not for us control, and a note box that is always visible rather than behind a control — a comment behind a click is a comment nobody leaves.

Skip is a real answer rather than a way to hide a card: "we showed them and it did not land" and "we never got to it" are different things to walk into a renewal conversation with, and only one of them is fixed by running the demo. Every tick records who made it — which matters more once the customer can make their own, which is the accessor slice.

Destroying a POV keeps this

Everything else in a teardown is removed. This is not: the POV row itself is marked destroyed rather than deleted because it is the record of something that existed, and the use-case history is what that record contains. The destroy job logs the summary — "use-case record kept: 9 of 14 run, 2 skipped" — at the moment somebody is closing the evaluation out, which is the one time anybody reads it.

The design note, including the accessor identity that is not kept, is in design/use-cases.md.

Vendor access: letting a third party into the lab

POV page → a POV's name → Access.

The accessor below is a door into this dashboard. This is the door into the lab — a PRA login that opens this POV's jump items and nothing else, in the customer's own appliance, on their own clock.

It closes a real gap. A POV wired into PRA already has a jump item per VM, through the Gateway installed inside the environment. Until this, only users who already existed in that appliance could launch one, so the items were correct and unreachable by the prospect. PRA's own answer to that is Vendor Onboarding, and this drives it.

Four objects, all named after the POV

The Jump Group is the part worth understanding, because it is why this could not simply be bolted on. A PRA Group Policy grants access by Jump Group, and a POV's jump items used to go into the Jump Group named on the tenant — one group shared by every POV on that appliance. A vendor attached to it would reach all of them. So a POV now gets a Jump Group of its own, and the vendor's policy names that one group.

A POV wired before this will say so

If this POV's jump items are still in the tenant's appliance-wide group, the card refuses and says why rather than offering a button that over-grants. Underneath the refusal it offers Move to its own Jump Group, which is the fix: it destroys this POV's jump items and rebuilds them in pov-<name>, then the vendor group can be created.

Two things to know before pressing it:

• Nobody can launch a session on this POV while the job runs. A jump item names its Jump Group when it is created and there is no update for that, so moving one means destroying it and building a new one. A Windows guest's Vault account is rebuilt with its jump item, because the two live in one Terraform workspace.
• Nothing else moves. This POV's managed systems, Entitle integrations, Gateway, accessors and share link are all left exactly as they are.

If an item cannot be destroyed, the job stops before creating the group and says so — items split across two Jump Groups would let a vendor reach part of the POV with nothing on the screen saying which part. Press Wire up to rebuild whatever did come out (back into the tenant's group, where the rest still are), sort the failure out in PRA, and move again.

Pressing Wire up on its own will not move the items, and says so in the job log: filling in a POV's gaps should not quietly tear down items that are working. And you can decline the whole thing — the dashboard login below and the share link both still work for a POV on the shared group.

Giving somebody a login

Press Create the vendor group, then fill in an email and press New vendor login.

PRA has no invite call. Nothing is emailed: the notification settings on a Vendor Group email your PRA administrators, not the vendor. So the dashboard creates the account and shows you a username and password once, which you hand over — and the account is set to require a password change at first sign-in, so the value you sent stops working as soon as they have used it. The email you type is a label, and what PRA shows on the account.

The email is required — PRA's vendor user has four mandatory fields and the address is one of them, alongside a display name (left blank, the dashboard uses the address). If the appliance refuses a login, the red banner now carries PRA's own field-level reason after Validation Failed — "the email address has already been taken", a password-policy complaint, and so on — which is the thing to act on.

The password the dashboard generates satisfies PRA's default policy by construction: twenty characters with at least one upper, one lower, one digit and one symbol, and none of Il1O0 so it survives being read down a phone line. If your appliance's policy is stricter than the default — a longer minimum, a banned character — the create will still fail, and the banner will carry the appliance's own wording under password:. That is a site setting; loosen it, or say so and the generator can be widened.

They sign in to PRA itself, not to this dashboard, and see this POV's jump items only.

Requiring TOTP

Tick Require TOTP for vendor users to set the POV's vendor Group Policy to two_factor_type: require_totp. Each vendor then has to enrol an authenticator app at their next PRA sign-in, so tell them to have one ready when you hand over the login.

The box works before or after the vendor group exists. Before, it is recorded and applied when you press Create the vendor group. After, it changes the live policy in place. It never re-creates the group, because PRA deletes a vendor group's users along with it and every login you had handed out would stop working. Unticking it sets the policy back to PRA's default, optional.

If you have built a self-registration portal in /login, paste its URL on the PRA tenant (Settings → Integrations → tenants) and the card will show it with a Copy button. The dashboard cannot create one: Portal Settings and the Email Domain Allow List are not in the Configuration API at all, so there is nothing to automate. The Network address allow list is in the API, and the card offers it.

It expires, and never outlives the POV

Seven days by default, always shortened to the POV's own expiry — ask for thirty on a POV with five left and you get five. PRA enforces that on its side, per Vendor Group, and expired accounts are deleted a week later so you can still see who had access during a post-mortem.

Belt and braces, as with accessors: destroying a POV removes the vendor group first, ahead of everything else, because of the three doors a POV holds open this is the only one whose holder is neither in your account nor in this dashboard. A sweep on the POV reconcile pass catches the rest — groups whose clock ran out, and groups whose POV is already gone.

What it will not do

It will not adopt anything. A Jump Group, Group Policy or Vendor Group already in the appliance that this dashboard did not create is a refusal naming it, never a reuse — a policy scoped to a group somebody else filled would hand a third party whatever is already in it. Deleting follows the same rule: only names carrying the pov- prefix, and only user accounts carrying povvnd_, so a vendor your customer added by hand is safe from this screen.

Accessors: giving the customer a login

POV page → a POV's name → Access.

The share link below is a door into the lab. An accessor is a door into this dashboard: an ephemeral login, bound to one POV, that opens that POV's use-case checklist and nothing else. It exists so the evaluation continues when nobody from your side is on the call, and so the prospect's own view of what they have covered is theirs to keep.

Accessor, or a real user scoped to one POV?

There are two ways to let somebody outside your team tick off use cases, and they are for different people.

Rule of thumb: if you would put their name in an org chart, give them a user with a POV grant. If you are emailing a link to an evaluation, mint an accessor.

The use level is the important half of that grant. With read alone they can look at the checklist but not tick it, and a checklist nobody can tick is a screenshot. With write they could provision and destroy POVs. See Permissions for the whole model; a POV they were not granted answers "No such POV environment", the same as an id that does not exist, because confirming somebody else's POV exists is itself a leak.

Three properties are not configurable, for the same reason the share link's three are not.

It can only ever reach its own POV

Not "has few permissions" — cannot reach anything else. Every other route in the dashboard refuses it server-side, on an allowlist rather than a blocklist, so a page added next month is refused before anybody remembers to think about it. It is invisible on the Users page, it cannot be granted anything through the Entitle integration that grants dashboard permissions, it cannot open a job's Live Output, and it cannot be handed a personal access token. An admin cannot promote one by editing it, either: those routes refuse and point back here.

It expires, and never outlives the POV

Fourteen days by default, and always shortened to the POV's own auto-delete date. Ask for longer than the environment has left and you get what the environment has left.

Belt and braces, because the failure mode is a credential nobody associates with anything any more: destroying a POV removes its accessors first, ahead of the share link; the auto-delete timer goes through the same job, so a reaped POV takes its logins with it; and a sweep on the POV reconcile pass catches anything the other two missed — expired logins, and logins whose POV is already gone. That sweep does not depend on the auto-delete timer being on, because a fresh POV instance starts with it off.

The use-case record is deliberately not removed with them. An accessor is a credential; the checklist is the account of what the evaluation covered.

The password is shown once

There is no reveal button, unlike the share link's. That link's password has to be re-readable because you read it to a customer days later; an accessor that has lost its password is replaced, which is one click, leaves an audit line, and ends with a credential exactly one person ever saw. Minting and revoking are both audited, so "who could log in to this POV" is answerable afterwards.

What they can do with it

They land on their own page — their POV's name, the lab link, what is set up on each machine, and the checklist.

They tick cards off themselves, and every tick is recorded as theirs, so your Use cases tab distinguishes "we showed them" from "they did it". They can leave a note on any card, and those come back to you on the same tab, marked as the customer's. A note is not a verdict: somebody writing "couldn't get this working" on a card they have not marked leaves exactly that, and the card stays unmarked.

Your ticks and theirs live on the same row, and neither erases the other's note.

They also get the lab link and, on request, its password — revealed one press at a time and audited, the same as when you reveal it. What they do not get is anything that is an identifier inside your appliances: no jump item ids, no managed account ids, no integration ids, no tenant names, and none of the wiring errors written for you. That list is a projection built for them, not your view with fields removed.

Where they come from

Two ways, and the Access tab shows which for every row.

By hand. Fill in an email — a label, so you can tell two accessors apart; nothing is sent to it — and press New accessor. Give the customer the username and password on the spot. They sign in at the normal /login and land on their own page.

From Entitle. This dashboard hosts an Entitle Remote Adapter in Ephemeral Accounts mode at /api/pov/accessor/rest, so a prospect can request access in Entitle and have the login minted, and removed, by the grant itself. Register with Entitle on the Access tab creates that integration in this POV's own Entitle tenant — not the instance's, and not one shared between customers: the asset is the POV.

Four things have to be true first, and the button is replaced by the reason when one is not:

The secret is deliberately not entitle_rest_secret: that one authenticates an integration that grants dashboard permissions, and this one mints logins. Give Entitle the same value as a bearer token.

⚠️ Check the connection mode once. Whether Entitle infers Ephemeral Accounts from the route set, as this assumes, is unconfirmed against a live tenant. After your first registration, open the integration in Entitle and confirm its Connection setting says an Ephemeral option — if it says Standing, tell us, because the discriminator is real and belongs in the registration. Minting an accessor by hand does not depend on this at all, which is why that path exists.

Removing the integration does not revoke logins that already exist: those are accounts here, not grants there. Destroying the POV removes the integration first and the logins immediately after — in that order, because a live integration can mint a new accessor while the destroy is running.

The asset Entitle sees per POV is pov:<environment id>, and the account it mints is always named povguest_…. That prefix is load-bearing: the delete route refuses any name without it, so the integration can never be talked into removing one of your accounts.

What a POV leaves behind

POV page → Past tab, or the Summary tab on any POV. The Past tab appears once a POV has been destroyed.

Destroying a POV removes the environment, the logins, the jump items and the integrations. It does not remove the account of what the evaluation covered — that row is marked destroyed rather than deleted precisely because it is the record of something that existed, and the checklist is that record's contents.

Until now nothing could reach it. The table of POVs filters destroyed ones out, which is right for a list of things you can act on, so a finished evaluation appeared nowhere. Past POVs is the way back: name, when it started, what it was wired into, how much was covered, and whether the customer worked it themselves. Clicking one opens its Summary.

The summary, and one distinction in it

The Summary tab is the same on a live POV and a finished one: coverage overall and per product group, every card somebody ticked or skipped, and what was said — the customer's own notes, marked as theirs.

One thing it is careful about. "A login was issued" and "they used it" are different facts, and only the second is evidence. The page says the customer worked the checklist themselves only when a card was actually ticked by them; the Past POVs table reports the two separately, so a login nobody opened reads as exactly that.

Copy as Markdown puts the whole thing on the clipboard — for a renewal note, a CRM, or an internal write-up. It is copied rather than downloaded because that is where it is going anyway.

The customer-facing share link

Everything above is something an SE touches. This is the one artifact a customer opens: a single URL onto the POV's desktops, published by the lab platform. On Skytap it is a publish set; on the POV page it is the Share column.

Three properties are not configurable, because each one exists to stop a specific way a POV link goes wrong.

It always has a password, and the password is generated

Skytap treats the publish set's password as optional. This does not, and there is no field to type one into. A blank password box is how an anonymous door into a lab holding a Gateway, a Resource Broker and a set of Entitle integrations gets left open — and an SE's usual password is barely better.

So the dashboard generates a 20-character password, hands it to the platform, and stores it Fernet-encrypted alongside the POV's other secrets (pov/<env-id>/share_password, the same shape as the Gateway deploy key). It is shown once when you share, and re-readable afterwards from the password button — that read is audited, because "who has this link's password" is the first question asked when a URL turns up somewhere it should not have.

The alphabet excludes I l 1 O 0. These get read down a phone line more often than anyone plans for.

It always expires

There is no "never" option. The failure mode of a POV share is not that someone guesses the URL — it is that the link outlives everyone's attention: the evaluation ends, the environment sits on suspend_on_idle, and the URL keeps working for months.

The expiry is chosen in this order:

1. what you asked for, if you typed a number of days (1 to 90, refused outside that rather than clamped);
2. the POV's own auto-delete date, if it has one — so the link cannot outlive the environment it points at;
3. otherwise 14 days.

Skytap enforces the expiry itself, so an expired link is already dead. The page shows it as expired rather than clearing the row, because during an evaluation the fact that a link was shared is worth keeping.

The expiry crosses to Skytap as two fields, expiration_date and its companion expiration_date_tz. The date carries no zone of its own and Skytap refuses the pair when only the date is sent — with {"field":"expiration_date_tz","message":"Expiration date tz is invalid"}, an error naming a field nothing set. The dashboard sends the date in UTC and the zone as UTC, together, and refuses an unparseable expiry before the call rather than letting Skytap answer for it. If an account rejects that zone name, the error says which one went out and where to change it.

Re-sharing replaces; revoking is its own button

Re-share revokes the current publish set before creating a new one, and mints a new password. Leaving the old one would give the POV two live URLs and one stored id — the second could never be revoked from here again. It also means re-sharing is a real remedy when a link went to the wrong person.

Revoke kills the link without touching the POV. The platform call happens first and its failure is not swallowed: clearing the row while the URL still worked would leave a live share nobody could find, let alone kill.

Both are also reachable from the API:

POST   /api/pov/managed/{id}/share          {"days": 7}   -> the link and its password
DELETE /api/pov/managed/{id}/share                        -> revoke
POST   /api/pov/managed/{id}/share/reveal                 -> the password again, audited

The URL is shown with a copy button rather than as a hyperlink. It is a customer-facing address, and an accidental middle-click from this page is an SE opening a session as the customer.

A platform that cannot do this

The Share column reads not supported when the platform's share_link capability is false, and the API refuses with a message pointing at PRA instead — the jump items the wire-up created already reach these VMs, which is the better answer for a customer who needs audited access rather than a URL. Skytap supports it; the column exists so the second adapter degrades explicitly instead of 500ing from inside a job.

Teardown

Destroy revokes the share before anything else, ahead even of the PRA jump items. It is the only artifact somebody outside the account can be holding, so the window where it still works is the one worth making shortest.

It never blocks the destroy. Deleting the environment removes its publish sets server-side anyway, so a failed revoke costs a note in the job log rather than a stranded POV — and the row is cleared regardless, so a destroyed POV is never left advertising a link.

Failure modes

The share link 400s with "has no share links". The platform's share_link capability is false. Give the customer access through PRA instead — the wire-up's jump items already point at these VMs.

"this POV has no stored share password". The link predates the stored password, or the password was cleared. Re-share: it publishes a new URL and a new password together, which is the only way to get back to a consistent pair.

"publishing the share link failed: … publish_sets failed (400): … Expiration date tz is invalid". Skytap did not accept the expiry's timezone. Before this was fixed the dashboard sent no timezone at all and every share failed this way; a current build sends UTC, and the message names the zone it sent. If it recurs, that account wants a different one — SHARE_EXPIRY_TZ in services/skytap_service.py.