Manage builders and viewers

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

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 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, grant Wisty tab visibility if they need the launcher, then share an app with their org. 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

Changing app sharing is covered in Share and open apps. Use Unpublish 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.

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. 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 for reconnect steps.