> ## Documentation Index > Fetch the complete documentation index at: https://wisty.ai/docs/llms.txt > Use this file to discover all available pages before exploring further. # Manage builders and viewers > Grant building access, manage viewer access, and understand what each disable action stops. Assign **Wisty Builder** in Salesforce to let someone build inside Salesforce. Use **Host orgs** in the Wisty web app to control how a linked org opens shared apps. ## Choose the right access control | Person | What controls their access | | ----------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------- | | Someone building from a Wisty account | Membership in the Wisty team. The Salesforce builder permission isn't required for this path. | | Someone building inside Salesforce | The **Wisty: Build Apps** custom permission, included in **Wisty Builder**. | | Someone opening apps inside Salesforce or through a Salesforce Web link | Access to Wisty's Salesforce External Client App, the linked org, and the app's sharing settings. No Wisty viewer permission set is required. | [Salesforce Web](/docs/getting-started/key-concepts#salesforce-web) links open published apps; they don't provide the builder. In every viewing path, apps call Salesforce as the person using them. Their object permissions, field permissions, and record access still apply. Salesforce admins manage the package, permission sets, and Salesforce sign-in policy. Wisty team admins manage the linked org's controls under **Host orgs**. ## Grant building access in Salesforce 1. In Salesforce **Setup**, open **Permission Sets**. 2. Select **Wisty Builder**, click **Manage Assignments**, and add the person. 3. Have them open Wisty again to pick up the [builder](/docs/getting-started/key-concepts#builder) role. You can instead add **Wisty: Build Apps** to a permission set you manage. The custom permission is what Wisty checks. The standard System Administrator profile may already have it from an admin-only package install. For [viewers](/docs/getting-started/key-concepts#viewer), grant [Wisty tab visibility](/docs/salesforce-setup/install#show-the-wisty-tab-to-viewers) if they need the launcher, then [share an app with their org](/docs/publishing/share-apps). Giving someone the builder permission doesn't expand their Salesforce data access. ## Remove building access 1. Remove the person's **Wisty Builder** assignment in Salesforce. 2. Check their other permission sets and profile for **Wisty: Build Apps**, and remove any remaining grants. Wisty checks this permission live before generation and publishing. The next attempt is refused once the grant is removed. If Salesforce can't confirm the permission, the action is refused; a denied generation costs no credits. A generation already in progress can finish. Other builder actions, such as opening a project or changing its sharing, may remain available until the existing Salesforce session refreshes, for up to 15 minutes in Canvas. Removing the builder permission doesn't remove viewer access. Keep their tab visibility separately if they should still use the launcher. ## Choose how to stop access | Action | Effect | Already-open apps | | -------------------------------------------- | ------------------------------------------------------------------------------------------------------------ | ----------------------------------------------------------------- | | Remove an audience from an app's **Sharing** | That audience can't launch the app again. Other audiences keep access. | Reads may continue until reload or session expiry, up to an hour. | | Turn off a host org's **Sharing** | Shared apps stop launching from that org, and builders can't add new shares to it. Existing shares are kept. | Reads may continue until reload or session expiry, up to an hour. | | Turn off **Salesforce Web** | Salesforce Web links stop working for that org. Canvas access is unchanged. | Salesforce Web requests are refused immediately. | | **Unpublish** an app | The app stops launching for every audience. The project and its history remain. | Subsequent Salesforce requests are refused. | Changing app sharing is covered in [Share and open apps](/docs/publishing/share-apps). Use [Unpublish](/docs/publishing/publish#take-an-app-offline) when the whole app needs to go offline. ### Turn off sharing for an org 1. In Wisty, open **Host orgs** and select the org. 2. Open **Sharing** and turn off the switch. The status changes to **Sharing off**. Existing shares work again when you turn sharing back on. This control governs shared apps; it doesn't remove someone's builder role or their ownership of a project. ### Turn off Salesforce Web 1. In Wisty, open the host org. 2. Select **Salesforce Web** and turn off the switch. Access is blocked immediately. Wisty then deletes the stored Salesforce Web sessions and credentials. This cleanup runs after the switch changes; it isn't required for the access block to take effect. ## Remove the host org Use this when the Salesforce org should no longer be linked to your Wisty team. 1. Open the org under **Host orgs**. 2. Open the actions menu next to its name and choose **Remove host org**. 3. Review what's being removed, type `delete`, and click **Remove org**. This removes the host-org link, its pinned apps and sharing grants, activation codes, and associated connection/session records. Linking it again requires a new activation code, and you'll need to share and pin apps again. For a temporary pause, use **Sharing** or **Salesforce Web** instead of removing the host org. ## Remove Salesforce app access Salesforce's sign-in policy controls who can authorize Wisty. Under **All users can self-authorize**, revoking a person's authorization only makes them approve Wisty again. To restrict future authorizations, [pre-authorize the intended users](/docs/salesforce-setup/install#pre-authorize-users). Review existing authorizations as well: changing the policy doesn't by itself revoke an earlier approval. To revoke an existing approval, open the app's **OAuth Usage** in Salesforce **Setup** and revoke the person's Wisty entry. Review their profiles and permission-set access too if they must stay blocked. For someone using a Wisty web account, revoking their Salesforce authorization breaks that Salesforce connection. Wisty shows **Connection error** until they reconnect. This doesn't remove their Wisty team membership. See [Fix common problems](/docs/help/troubleshooting) for reconnect steps.