Skip to main content
Plexara
Governance7 min read

802 - Requests for access: asking, approving, and the limits on both

What a signed-in person sees when a link leads to an item they cannot open, and the request they send with an optional message. The owner approves as viewer or as editor, or declines, from the email, from Access requests at the top of the Inbox, or from the item’s Share dialog, and approving is a share, so the link they followed opens with no further step. One waiting request per person per item, three asks a day, expiry after the period an administrator sets under Admin > Settings > Access requests, and the setting that decides whether the request page names the item.

What you will take away from this lesson

Links travel further than shares. A colleague pastes a dashboard into a chat thread, and somebody who was never added follows it. Without a way to ask, that person messages the owner, the owner opens the dialog, finds the address, and shares by hand.

Plexara turns that into a request the owner answers with one click. This lesson follows a request from the page the person lands on to the share that answers it, and the settings that bound it.

Learning Objectives

  1. 01Describe what a signed-in person sees when a link leads to an item they cannot open.
  2. 02Answer a request from the email, the Inbox, or the item’s Share dialog.
  3. 03Explain why approving needs no further step from the requester.
  4. 04State the limits on asking and the expiry an administrator sets.

Where this lesson sits

Lesson 801 covered who the Share dialog lets in. This lesson covers the people it has not let in yet, and how they ask.

800 Series: Working with People Outside the Company

Open index

The 800 series builds on sharing within the team from lesson 303 and registers a client’s file the way the 500 series does. Every example is on the ACME demo tenant, with a fictional supplier, Blue Harbor Wholesale.

From the link to the answer

A request has five steps, and the person asking takes only the first two.

A request, from the link to the answer

  1. 1

    The person follows a link

    Signed in, they reach an asset, a collection, a prompt or a file they cannot open. The page says You do not have access to this item and names its owner.

  2. 2

    They ask, with an optional message

    Request access sends the request with whatever they wrote, for example which report they need and why.

  3. 3

    The owner is told

    By their own notification preferences: an email with the answers in it, and a row under Access requests at the top of the Inbox.

  4. 4

    The owner answers

    Approve as viewer, Approve as editor, or Decline, from the email, the Inbox, or the item’s Share dialog, which lists waiting requests.

  5. 5

    The requester is told

    Either answer is emailed to them. An approval is a share, so the link they followed opens with no further step.

An administrator sees and answers every request on the deployment, which covers an item whose owner is away.

The page a signed-in person sees for an item they cannot open: a lock icon, the item's name, who owns it, an optional message box, and a Request access button.
What the person asking sees.

Where the owner answers

The same request appears in three places, and an answer given in one clears it from the others.

Three places to answer

The email

The notification carries Approve as viewer, Approve as editor and Decline, so a request can be answered from a phone without opening the portal.

The Inbox

Access requests sit at the top of the Inbox, above feedback threads, with the requester, the item and their message.

The Share dialog

Opening Share on the item shows the waiting requests beside the people who already have access, which is the place to answer when the owner also wants to adjust other shares.
The owner's Inbox with an Access requests block above the threads: one request naming who asked, the item, and their message, with Approve as viewer, Approve as editor and Decline.
A request at the top of the owner's Inbox.

Two requests on the demo tenant

The supplier persona from lesson 805 has no share on ACME’s internal reports. Its first person followed links to two of them and asked for both.

Two requests from Blue Harbor Wholesale on the demo tenant

ACME 2025 Merchandise Mix

Approved as viewer

Dana Okafor at Blue Harbor Wholesale asked for the category mix to plan the next quote. The owner approved it as viewer from the Inbox, which recorded a viewer share to Dana on the report.

Supplier pipeline

Declined

Dana asked to check the supplier’s onboarding status. The report lists every applicant, so the owner declined it, and the page still reports no access.

Opening the pipeline link again while the first request waited showed that the request had been sent and offered no second form. Both pages named the owner and neither named the report, because the demo tenant leaves the item's name off.

Limits on asking

Four rules keep requests useful to the owner and stop them from becoming a channel for unwanted mail.

Limits on asking

RuleWhat it does
One waiting request per itemAsking again while one waits returns that request and notifies nobody
Three asks per item per dayStops a request from becoming a way to send the owner mail
ExpiryA request no one answers expires after the set period, 14 days unless changed, and can then be made again
Whether the page names the itemStarts cleared, so a link alone does not reveal what an item is called; an administrator can tick it

The settings an administrator controls

Two settings shape every request on the deployment.

Admin > Settings > Access requests

Show the item’s name on the request page

Off

With it off, the person who cannot open the item sees that it exists and who owns it, not what it is called. The ACME demo tenant leaves it off.

Requests expire after

14 days

The period a request waits for an answer. The ACME demo tenant uses the standard 14 days.

Both settings are in the portal under Admin, so an administrator on your team changes them and the change applies to the next request.

Admin > Settings > Access requests: a checkbox to show the item's name on the request page, off, so the page says only that the person does not have access and names the owner, and Requests expire after set to 14 days.
The two settings for requests, under Admin > Settings > Access requests.

Requests, end to end

A person who reaches an item they cannot open asks once, the owner answers from wherever they are, and the approval is an ordinary share that the owner can change or remove in the dialog later.

Key terms

Three terms cover access requests.

Key Terms

Access request
What a signed-in person sends from an item they cannot open. The owner approves it as viewer or editor, or declines it.
Approval
A share to the requester with the chosen role. The link they followed opens from then on.
Request expiry
The period after which an unanswered request lapses, set under Admin > Settings > Access requests.

Related reading

governance
Governance

403 - Sharing prompts, and closing the loop with feedback

A procedure is only worth as much as the people who can run it. Plexara distributes a prompt two ways: a direct share to the teammates or teams you name, or a promotion to a whole role or company through the admin review queue. A shared prompt is live, not a copy. Feedback threads then carry corrections back, with a validation step and a path into the knowledge catalog, and the deprecate-and-supersede lifecycle retires old versions cleanly.

Governance

505 - Next month’s file

The new sheet arrives. Replacing the file’s content writes a new revision, and the registered table keeps reading the old one until it is registered again under the same name; the Scratch Tables page says so. This lesson covers the two cases that look alike and behave differently, moving the table forward, unregistering, what deleting the file does, saving the monthly procedure as a prompt, and the point at which a monthly file needs more than a join, which is where the 600 series begins.

Governance

605 - What a run may do, and the record it leaves

A run presents the roles its author held at the save, every call is authorized at that moment, and narrowing the persona takes effect on the next run. A save requires one format, work in main(), the structural rules, and tests that pass, reach the code, and read the data, and refuses a credential-shaped literal. A new version is replayed against recent successful runs, and one that changes what the automation does waits for the person’s agreement to a plain-language summary. The dialect has no network, no filesystem, no clock, and no imports beyond pinned libraries, so everything a script does is a platform call audited under the script’s own identity. The lifecycle, who sees what, state and checkpoints on a failed run, ownership and an administrator’s transfer, and the administrator’s view of every script and every run.