Salesforce Stack Exchange is a question and answer site for Salesforce administrators, implementation experts, developers and anybody in-between. It only takes a minute to sign up.
Sign up to join this community
We are performing a security review of the WorkBench tool before allowing external consultants access to our Salesforce organization for viewing the structure and relationships to develop reports.
I found the Wiki with documentation about security , but are there any architecture diagrams describing the WorkBench architecture?
is there any best practices tor specified permissions to minimize what can be done via workBench?
The Workbench has access to anything the user has access to. This is how the Salesforce API works in general. You must set up your user's Profile and Permission Set settings, as well as any sharing settings, correctly in order to avoid allowing the user to do something they should not. I suppose, as far as best practices, would be to assign those users to the Read Only/Minimum Access profile, then add on permission sets to allow additional access as needed. There's no particular "architecture" diagram, but it is open source, so you can review it for yourself.
The code for Workbench is publicly available here. The tool is currently in maintenance-only mode, with only security and API updates and no new features. It is not a Salesforce product and you cannot get help through their support teams.
In theory, anyone could fork the code, set up a fly-by-night clone that captures the credentials to an environment, and position the server properly in a search engine to phish well-intentioned junior admins.
Unless it is running locally from your machine in a container image or in an internal server that you maintain, the consulting team is better-off by using a more modern toolkit, since there is virtually nothing in Workbench that cannot be achieved with a combination of VSCode, the Salesforce CLI, Postman, or even good ol' Dev Console.
