“Don’t forget the Workbench!” I think I utter this to at least one team member every week at Red Argyle.
Workbench is a lesser-known (and oft-forgotten) tool in the Salesforce landscape. It’s been around for years and it’s not especially fancy to look at, but it’s packed with features that make the lives of developers and administrators easier.
In essence, Workbench takes all of the Salesforce APIs and wraps their features in a UI that lets you review objects, manage data, deploy and retrieve metadata, and run Apex, to name a few. It’s an open source project managed on Github. Salesforce hosts a version of it, and you can also download and run it for yourself.
Now, to be fair, there’s nothing that Workbench does that you can’t do with the Salesforce Admin UI, Developer Console, Mavensmate, Force.com IDE, etc. The difference is that Workbench combines almost all functionality in one place and is very easy to access–no installs, you just log in to a website with your Salesforce credentials and get to work. If you’re already logged into Salesforce, it’s even easier through the magic of OAuth.
The features of Workbench are vast, and I’m going to dive into some of them over a few blog posts to explain their value and how I end up using them almost daily for client projects and product development. Here’s a great starting point for that listing:
Salesforce Workbench: Retrieve and Update
They may seem simple, but the “Retrieve” and “Update” functions in Workbench are even more powerful than expected as they allow you to quickly and clearly view and edit records.
The “Retrieve” function isn’t obvious at first glance–it doesn’t appear in Workbench’s menu bar. You need to use a special URL in Workbench to take advantage of it. By default, Retrieve is an internal page that Workbench uses to allow users to navigate to a detail view of a record after running a query. However, you can short-circuit the page by setting the “id” parameter in the URL to whatever record you choose.
Here’s an example of what that looks like: https://workbench.developerforce.com/retrieve.php?id=SALESFORCE_ID_OF_THE_RECORD
The resulting view is a very plain listing of fields (by API name, my favorite) and their values. This is very helpful for reviewing specific record data that may not be included in the page layout, as is often the case when you’re building complex processes that rely on “under the hood” fields to manage state and key data points.
At the top of the Retrieve view is the “Update” button. Click that and you’ll get a similar view, but now with editable fields. Update values to your liking and save the record. Changes are saved back to Salesforce. I like to use this for manually changing and resetting those “under the hood” values mentioned above, allowing my page layouts to remain untainted with fields that otherwise make no sense to edit users (which are easily forgotten…then deployed to production for the whole organization to see and wonder about).
Retrieve and Update are both driven by passing a Salesforce ID on the URL. Want to get clever? Build some custom links with dynamic parameters into Workbench and drop those on your records in Salesforce.
https://workbench.developerforce.com/retrieve.php?id=SALESFORCE_ID_OF_THE_RECORD
https://workbench.developerforce.com/update.php?id=SALESFORCE_ID_OF_THE_RECORD
Another great feature of these two fields is that they respect object and field-level security settings. You can “log in as” any user or as an administrator and retrieve a record to determine if and why a user’s profile is or is not allowing them to view or edit a certain field. Again, it won’t give you the answer, but it will make it clear what fields can’t be accessed or updated because they won’t be present in the Retrieve or Update UIs.
Retrieve and Update are the first simple but useful Workbench functions we’ve reviewed. Tune in for future Workbench blog posts where we’ll review schema, browse the REST API, run Apex, and deploy and retrieve metadata. Happy Workbenching!
