Cloudtoolkit.co is a nifty collection of web apps created by Ben Edwards (from Auckland, New Zealand).
This comprehensive, step-by-step guide will introduce you to the suite and help you get started.
Upon opening the Cloudtoolkit.co homepage, you’ll be presented with a smart assortment of useful tools and applications. In this article, I will walk you through some of the various tools and how to use them.
I use Org Compare after a production deployment to self-validate that the production org is the same as the sandbox which had been tested.
Cloudtoolkit.co is an open-source app; so if you’re a bit hesitant to use this app in production and the signed-off sandbox, create two new sandboxes (one copied from production and the other cloned from the signed-off sandbox) and compare these new sandboxes.
Step 1: Log into Org One.
Step 2: Review requested permissions.
Step 3: Log in to Org Two.
Step 4: Select your options – Tooling API vs Metadata API. If you only want to compare Apex code, choose Tooling API. It is faster since it only supports Apex Classes, Components, Pages, and Triggers. Use Metadata API if you want an all-inclusive comparison.
Step 5: If you are comparing large orgs, tick “Email me when ready”. Comparing large orgs takes time, so now you can close your browser tab and get notified by email when the result of the comparison is ready.
Step 6: Select your options. Tick the “Contextual Diff” checkbox if you only want to see the different lines of metadata. If you would like to inspect full metadata files containing the differences, leave it unticked. Both options have their uses, depending on what you require, how familiar you are with the project, or depending on the length of the metadata files.
Step 7: Initiate Compare.
Step 8: Wait for your results.
Step 9: If you had ticked “Email me when ready” earlier, you can close the browser tab and open the email from Org Compare when it arrives. Otherwise, do not close the browser tab.
Step 10: Review differences.
Step 11: Review line-by-line differences in files.
Step 12: Download the offline file.
Step 13: Unzip the files and view them offline anytime.
Do you need to switch off a bunch of Validation Rules, Process Flows, or Triggers to aid a bit of data loading? Look no further. In our barebones example, we will demonstrate how to switch off a trigger using Config Switch.
Step 1: Confirm that the sample Trigger is active.
Step 2: Log into Config Switch.
Step 3: Review requested permissions.
Step 4: Get Metadata.
Step 5: Wait while querying metadata.
Step 6: Review Validation Rules to be disabled or enabled. (In our example, we only have one Trigger to disable.)
Step 7: Review Workflows to be disabled or enabled.
Step 8: Review Process Flows to be disabled or enabled.
Step 9: Finally, review our sample Trigger to be disabled.
Step 10: If required, you can also review its code. (My sample Trigger is empty.)
Step 11: Deactivate Trigger and Deploy Changes.
Step 12: Wait while deploying.
Step 13: Deployment complete (this took me a few seconds).
Step 14: Review that Trigger has actually been inactivated in Salesforce.
Step 15: Messed up? No worries. Rollback to the original in a cinch.
Have you inherited a mammoth Salesforce org? Schema Lister is useful for making a spreadsheet UML of your org which you can study without distractions, or share with colleagues, without constantly logging into Salesforce Setup. No longer do you have to take on the job of a Salesforce archaeologist and dig through objects and fields.
The spreadsheet is also a good place to start a manual cleanup mission of your org, or just for record-keeping to keep your compliance team happy.
Step 1: Log into org.
Step 2: Review the list of requested permissions.
Step 3: Initiate “Get Schema”.
Step 4: Wait for results.
Step 5: View results.
Step 6: View results as single tab XLSX.
Step 7: View results as multi-tab XLSX.
The first time you were asked to create 20 fields, you were probably excited. Ever since, you have probably searched for less cumbersome ways of creating multiple fields. Field Creator provides an easy interface to set up and create multiple custom fields in one go – much easier than doing it one-by-one within Salesforce, as we shall now see:
Step 1: Log in to org. Note that only for this app, there is a dedicated “Developer” picklist. So unlike other apps, you shouldn’t use the “Production” option for Developer orgs.
Although, I am going ahead with my sandbox…
Step 2: Review requested permissions.
Step 3: Click on “Query list of objects”.
Step 4: Wait while the app queries for objects.
Step 5: Click on “Select Object”.
Step 6: Select object from the object list.
Step 7: Select field types.
Step 8: Select field options.
Step 9: Deploy list of new fields.
Step 10: Deploying fields.
Step 11: Fields successfully created.
Step 12: Check that the fields have been created in Salesforce. Also, note that Field Creator automatically adds the fields to all profiles, but not to page layouts. Modify your profiles and page layouts according to what you need.
Package Builder creates a list of your org’s metadata in an XML format. A developer can use this list (and the Salesforce Migration ANT Tool) to download actual metadata, deploy to another org, review differences with another org, or store it for record-keeping to keep your compliance team happy.
Step 1: Log into org.
Step 2: Review requested permissions.
Step 3: Choose your format of package.xml.
Step 4: Wait for the result to be generated.
Step 5: Voilà. The package.xml file loads in the same tab.
Code Scanner is a quick way to scan all your Apex Classes to see where they have been referenced. It’s useful for making a blueprint and for cleaning up unused or unreferenced code.
Step 1: Log into your org.
Step 2: Review requested permissions.
Step 3: Initiate scanning…
“Email me the results” didn’t work for me, so I kept it unchecked in the screenshot.
Step 4: Wait for the results.
Step 5: Here is a small example of the format of the results.
Summary
Cloudtoolkit.co is open-sourced on the creator’s Github page. However, please note that Cloudtoolkit.co is not endorsed or supported by Salesforce.
Just as you would do with any other app, before considering Cloudtoolkit.co for work, discuss with your org owner, client, or compliance team. Without permission, you shouldn’t log in. App logins get inscribed into Salesforce’s Login History, and non-compliance is a serious breach. Building trust and relationships should be one of the most important missions of your career.
Use your browser’s incognito mode. Logins and authorizations may or may not interfere with existing sessions, so just use incognito and skip the drama.
If you are a Salesforce newbie with a developer-edition org, choose “Production” from the OAuth login, not “Sandbox”. When I was a newbie, no one told me this!
Finally, be considerate in your usage as the hosting of these apps is paid for by the creator.
P.S. Thank you for sharing your creation with the world!
