> ## Documentation Index > Fetch the complete documentation index at: https://docs.parable.work/llms.txt > Use this file to discover all available pages before exploring further. # Pros Access > See every request a Parable Pro made to enter your Workspace, who approved it, why, for how long, and whether it read Provider data. # Pros Access ## Sources Docs: [Provider Policies](https://docs.parable.work/protection/provider-policies.md), [Protection Primer](https://docs.parable.work/protection/primer.md). Web App: Workspace administrators open **Protection → Pros Access**. A Parable Pro is a Parable employee. A Parable Pro can enter your Workspace only when a second Parable Pro approves the request. The access has an end time, at most 24 hours after the approval. Each request names its purpose, and you see it. ## What a Parable Pro must do to enter 1. The Pro asks for access in Parable. The request names your Workspace, the purpose, the second Parable Pro who must approve it, and the duration. The duration is 1 hour unless the Pro changes it, and it is never more than 24 hours. 2. The second Pro approves or refuses the request. A Pro can never approve their own request. A request that nobody answers in 60 minutes lapses. 3. The access starts at the approval and stops at the end time. The Pro, the approver, or another Parable Pro who can approve can end it earlier. The same rule applies to every Parable employee, super administrators included. A Parable employee who is also a member of your Workspace needs an approved request too. Their membership does not let them enter. Without live access, your Workspace does not exist for that Parable Pro. Every request to it fails as if the Workspace has no such name, with every kind of credential: a sign-in, a personal access token, an MCP token, and SQL over Flight. Your Workspace is not in their Workspace list, and sign-in does not take them to it. ## Two kinds of access | Access | What the Parable Pro does | | - | - | | **Support** | Enters as themselves, with their own Parable roles. | | **Impersonate** | Acts as one member that the request names, with that member's rights. A Parable Pro cannot impersonate another Parable Pro. | ## Provider Pools access Each request has a **Provider Pools access** switch. It is off unless the Pro turns it on, and the approver sees it before they approve. | Provider Pools access | What a Support access reads from your Provider Pools | | - | - | | Off | Nothing. A query to your Provider Pools runs and returns empty tables. Pages do not load their data, and Refresh and Preview do not run. | | On | What your Provider Policies give **Everyone else**. The Pro's own membership of your Workspace, if they have one, gives them nothing more. | | On, past your Provider Policies | Every row of every Provider table. Only a Pro whose Parable role already reads past Provider Policies in your Workspace can ask for it, and the approver sees it in words. | | Provider Pools access | What an Impersonate access reads | | - | - | | Off | Nothing. Parable does not read data as the member: SQL, Pages, Ponder, Refresh and Preview do not run. | | On | Provider data as the member reads it, under your Provider Policies. | Ponder's work that a Pro starts during an impersonation acts as the member under the same access. Parable checks the access on each request, on its own clock. When Support access ends, the next request and the next read are refused, also in the middle of a long query or a Ponder turn. Work that a Pro started during an impersonation, a Ponder turn or a Report run, finishes as the member, and its output stays in your Workspace; reading it needs a new access. ## Credentials do not outlive the access During Pros Access, Parable refuses to make a personal access token or to give an OAuth client access. A token or a client would keep working after the access ends. A personal access token that a Parable Pro made at another time gives no access to your Workspace by itself: it works only while its owner has live Support access. ## The Pros Access page **Protection → Pros Access** lists every request a Parable Pro made for your Workspace, also the requests that never started. It shows 100 requests at a time, newest first. **Show older requests** opens the next 100. | Column | What it shows | | - | - | | When | The time the access ran, or the time of the request. Under it: the time asked for, how long the Pro was in when the access ended early, or "asked" for a request that never started | | Status | Waiting for approval, Active, Ended early, Expired, Refused, Withdrawn, or No answer | | Parable Pro | The person who asked | | Access | Support, or the member the Pro impersonated | | Approver | The second Parable Pro, who shares the responsibility | | Provider Pools | Off or On | | Purpose | The reason the Pro wrote | Live access shows at the top, with the time it has left. Nobody can change or delete this list, Parable included. Parable keeps it indefinitely. A Workspace administrator can see the page. A custom role can see it when it has the **See Pros Access** permission. Parable's own services, which run your syncs and Pipelines, are not people, and they do not show on this page. ## What is audited * The request record: who asked, who approved, the purpose, the times, the duration, and Provider Pools access. * Each change of the request: the request, the approval or refusal, the withdrawal, and the end. * The start of each impersonation, with the request it used. A Parable Pro sees the same text before they send a request: * We keep this record indefinitely. * The customer sees this access in their Workspace. * We can tell the customer and our employees about it. * Use this access only for a legitimate purpose. * Improper access is a fireable offense. * Respect our customers. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.