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
- 01Describe what a signed-in person sees when a link leads to an item they cannot open.
- 02Answer a request from the email, the Inbox, or the item’s Share dialog.
- 03Explain why approving needs no further step from the requester.
- 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
- 801Who can open whatThe Share dialog by access: people and their roles, personas as groups whose membership is read when the item is opened, guests, and the one general link an item has.
- 802Requests for accessWhat a person without access sees, how the owner approves as viewer or editor or declines from the email, the Inbox or the dialog, and the limits and expiry an administrator sets.
- 803Posting to a channelPosting an item to a Slack, Mattermost or email channel as a link share of its own, what the channel sees, who the link opens for, and removing it.
- 804Portal permissionsThe persona editor by surface, one access level per portal area, the sharing permission, the access summary, and what deleting a persona checks first.
- 805Your clients as external peopleAn external persona per client organization, accounts that live in your identity provider, and the fixed limits: only what is shared, only shared threads, no sharing, no agent.
- 806Files from outsideUploads into an external person’s own folder, the External files folder staff open, and registering a client’s monthly file as a table beside the warehouse.
- 807Capstone: a supplier’s collection, thread and monthly fileAn ACME supplier collection shared with the supplier’s persona, a shared thread beside an internal one, and the supplier’s next price sheet registered and joined into the review.
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
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
They ask, with an optional message
Request access sends the request with whatever they wrote, for example which report they need and why.
- 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
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
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.

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.

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
| Rule | What it does |
|---|---|
| One waiting request per item | Asking again while one waits returns that request and notifies nobody |
| Three asks per item per day | Stops a request from becoming a way to send the owner mail |
| Expiry | A request no one answers expires after the set period, 14 days unless changed, and can then be made again |
| Whether the page names the item | Starts 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.

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.
