Custom Metadata, Find Usages and refined sObjects Inspector in the Bloom R18

We hope you've missed us over these past weeks, and we hope that you'll like what you will see in The Welkin Suite Bloom R18. We have started working on a very big update to the IDE that will bring you all metadata types and will change a lot of things of how we interact with Salesforce, but yes - started, but not yet finished 

However, we have a bunch of great updates today - starting from 5 features & improvements for the built-in sObjects Inspector and upto the Custom Metadata support and 'Find Usages' functionality in Apex.

Custom Metadata support

Yes, you're right - it's one of the most requested features that we have had over the last 3-4 months, and now it is here in the Bloom R18 release. While we're still working on supporting all metadata types that are available from Salesforce, we are adding the most important ones that are missing right now. Our thinking in doing this is that your waiting for the other Metadata types will be more enjoyable. Therefore, terms of Custom Metadata, The Welkin Suite supports both working on definitions and on records themselves, so let's see how to get your hands dirty with this new capabilities 

First of all, you can add existing Custom Metadatas to your existing project by using the 'Project Metadata Components' wizard which is available from both the project's context menu in the Solution Explorer and from the 'Main Menu → Project'. From here you can control Custom Metadata in the same way as any other metadata that is supported by the IDE, however when you include certain Custom Metadata to the project - both its definition and records will be added an updated over the time. The same logic applies to the project creation process - just check your needed items or subscribe to all new Custom Metadata items right from the first seconds of your project's life in the IDE.

Afterward you'll find your Custom Metadatas in the following locations (by default):

• In the 'objects' folder - Custom Metadata definitions with the '__mdt' suffix
• In the 'customMetadata' folder - Custom Metadata records with the '.md' extension

The cool thing here is that editing a Custom Metadata object is absolutely as easy as editing regular sObjects in The Welkin Suite - just double-click on any of them and you'll spot the already familiar sObjects Inspector. You can add new ones or modify existing fields using the GUI part of the editor or do all your changes directly in the XML definition of the Custom Metadata object - you're free to choose whatever is faster and more comfortable for you.

By the way - Custom Metadata objects are as well shown in the Admin Panel and in the Schema Explorer, so you won't lose them!

The last part of this new feature is having an ability to modify records of your Custom Metadatas in the IDE and, again, in two different ways:

• Editing existing records in a plain XML
• Editing existing or adding new records using the Custom Metadata Records Editor

You can open the new Custom Metadata Records Editor from the Main Menu using the Tools → Edit Custom Metadata Records command.

On the left side of the Custom Metadata Records Editor, you will see an already-familiar approach with the list of projects in your solution with child items representing different Custom Metadata objects. Once you select any of them - on the right sight of the editor you will see a table with the records that are available locally in your project. You can edit any existing record by double-clicking on any field and changing the value there.

Below the list of existing records, there always will be an available empty line - it's there for you to easily create new Custom Metadata records. Just double-click on any cell in that line, fill in values and it will be ready for deployment to Salesforce once you're done.

In the context menu for each cell in the table you can find some/all of the following options:

• Set the value for the whole column - 'bulk' apply the value from a selected field to all of the other records
• Set value to Null - if a selected field is Nilable, this option will set its value for the record to Null
• Set original value - reverts back the original value of a cell if you have modified it
• Remove record - if you have added a new record to the table but have not yet deployed it - you can remove it with this option

As you can see on the screenshots above - changed cell will be highlighted with a different background. You will also see a change indicator in the list of Custom Metadata on the left side - if any record was changed or added for a certain Custom Metadata object there will be a visual marker near its name in the list so you won't miss what was changed.

We are sure that having a handy way to work with Custom Metadata objects and records in the IDE will speed up your work with them, so if you haven't used them in your projects yet - consider doing this now 

Picklist Value Sets and other sObjects Inspector New Features

Global Value Sets

Today we are announcing a lot of changes around the sObjects Inspector - all of them were requested in one way or another by our great users!

The most important update related to the support of Global Value Sets (or Picklist Value Sets as shown in the org UI). These Value Sets are great option to save admins and developers time - you don't need to keep track of all similar/same picklist fields so you won't forget to keep them in sync manually. This is why it's very hard to find an organization where Picklist Value Sets are not being used, however till today they were not supported by The Welkin Suite, so let's see what've changed.

First of all, Global Value Sets are a separate metadata type, so you'll need to include them into your project - either during the project creation process or later using the 'Project Metadata Components' option for your project.

Once you have your Global Value Sets in the project, you can edit them as regular XML files that are located in the 'globalValueSets' folder by default.

At the same time - you will now see the proper information about your picklist fields that are using Global Value Sets directly in the sObjects Inspector:

If you need to change values in the value set - you can press the '...' button to edit the Picklist Value Set. Please pay attention the fact that you are editing the whole Value Set, so your change will also affect other objects and fields that are using that Picklist Value Set.

Identifying required fields faster

Another change in the sObjects Inspector aimed to help you answer the simple question "Is this field required?"in seconds without losing any details. And by 'without losing any details' we mean taking into account information about your page layouts and if a field is required there as well.

From now on you can get an absolutely clear answer to this question directly from the 'Fields' tab in the sObjects Inspector for a needed object - just take a look at the new 'Required' column:

In this column there might be two different icons for each field:

• The first icon means that the field is required on the object itself
• The second icon means that the field is required on one or more layouts in the project. If you'd hover over the icon - you will see the list of layouts where that exact field is marked as required.

Sure, there are still some ways to enforce a field to be required using Validation Rules or Triggers, but we don't think that they are used in more than couple percent of cases.

Fields Dependency Wizard

The next cool feature in the sObjects Inspector that is being released with the Bloom R18 version of the IDE is the 'Field Dependency Wizard' or just a simple way to work with dependent/controlling fields without a need to go back to a browser. You'll find a new button in the 'Fields' tab of the sObjects Inspector that will start this wizard.

As a first step in the wizard you should select/enter the following details:

• 'Controlling field' - controlling picklist. Both standard and custom fields are allowed here, and custom fields are highlighted with a different background
• 'Dependent field' - dependent picklist. Only custom fields are allowed.
• 'Delete Dependency' - if you select this checkbox, the dependency between these fields will be deleted, otherwise, on the next step, you will be able to create or modify it.

On the next step you will see a matrix that will allow you to configure the dependency between these fields:

• Values of the controlling field will be shown as columns
• Values of the dependent field will be shown as checkboxes in the each column

By setting checkboxes you can allow/forbid certain values of the dependent picklist according to the value from the controlling picklist. At the same time, there are bulk ways to control checkboxes - you can click on a column header to check/uncheck all checkbox in that column, or you can check/uncheck the first checkbox in each row to check/uncheck it.

In the lower part of the wizard you can see the 'Preview' section:

In this block, you can see two picklists - for both controlling and dependent fields and you can see what options you will have in a dependent picklist when you'd select any value from the controlling field.

Once you are happy with all the settings just hit the 'Next' button for this changes to be applied to the organization immediately.

Export FLS report to a .csv file

The next improvement you can find in the 'FLS' tab of the sObjects Inspector - a new button to export FLS settings to a .csv file. There is a lot of different reasons why you'd want to do this, for example:

• Share with a customer, for whom you are configuring the Salesforce organization
• Share with your teammate(s) for reference
• Do some magic in Excel or Google Spreadsheets
• Save as a human-readable backup for the future you

So no matter why you'd need to do this - you can find the new 'Report to CSV' button on the 'FLS' tab in the toolbar. Once you press it - just select the location and filename and the job will be done.

One important (and handy) thing to keep in mind is that the 'Report to CSV' functionality respects your filtering options, so if you've filtered the FLS tab to show only certain profiles and fields - you can be sure that only these details will get into the resulting .csv file.

Improvements for Fields Cloning

The last in this list of updates for the sObjects Inspector is Fields Cloning functionality. As we've released it a while ago, we've got some handy feedback on how to do some simple UX changes that will make the 'Clone Fields' functionality even better!

If you remember (here's a link to refresh it in your memory) - 'Clone Fields' allows you to copy one or multiple fields from one object to any other object(s) (including the same object) from 1 to however-many-want times, so it's an ideal solution for example for the Lead Conversion process setup - just select your custom fields on the Lead and clone it to the Account/Opportunity, for example.

Previously cloned fields were named like 'FIELDNAME_Clone1__c', 'FIELDNAME_Clone2__c' thus you were always needing to modify their names and labels to get rid of that 'CloneX' suffix. From now on the behavior is the same as you've seen in Windows Explorer when creating folders  If there is no field with such name in the target object - the name will remain the same. If there is such a field - it's index will be incremented as needed, so the name will be 'FIELDNAME1__c', etc.

While it's a really small change - it's impact is real and it saves clicks that are not needed.

Find Usages for Apex code

It's no longer needed to use the 'Find in files' functionality in the IDE to find where else your Apex variable, class, method, etc. is being used, because there is already an option to do this in a right way directly from the editor!

You can execute this search in 2 different ways:

• With a hotkey - Shift+F12 is the default one - will find the usages of the "item" that is located in the position of your caret
• Using a context menu in the Apex Editor - just right-click on any "item" that you'd like to look for and select 'Find Usages'

By using that strange term "item" above, what we mean is a variable, class name, interface name, method name, constructor name.

The results of the 'Find Usages' action will pop up in a new panel - you can use it as a regular window and close it once you've found whatever you were looking for, or you can dock it in the UI like any other panel in the IDE, so in the future it will be always be in the place you want.

In the 'Find Usages' panel, you will see all references to the item you've looked for, grouped by files.

In each results entry you will find:

• The type of construction where the search item was found - expression, method name, class name, etc - this will be shown using an icon;
• The location within a file in the format "line:column";
• The line of code where the item was found with the search item highlighted with a different background.

And, of course, you can double-click on any entry to be navigated to it directly in the editor.

Additionally, in the toolbar, you can find the following buttons that might help you navigating through the results faster:

• 'Expand all' - expands all groups (files) in the results list;
• 'Collapse all' - collapses all groups (files) in the results list;
• 'Go to definition' - does the same as a simple double-click - navigates you directly to the selected entry in the Apex editor;
• 'Go to the previous location' - navigates you to the previous result entry directly in the Apex editor;
• 'Go to the next location' - navigates you to the next result entry directly in the Apex editor;
• 'Copy' - copies the selected line of code to the clipboard;
• 'Clear the current list' - clears results in the panel;
• 'Cancel processing' - cancels 'find usages' operation if you don't need results anymore.

With the addition of the 'Find Usages' functionality you should no longer worry if you'd need to find where else the variable 'oldMap' (or put here any other common variable name) is used in your codebase, and there will be no more digging through hundreds of not-always-relevant results in the 'Find in files'!

Field Usage Report - now with Apex and in Managed Packages

We hope that you've already tried the great Field Usage Report since the last release of The Welkin Suite IDE, have you? Ok, just in case - here you can take a look how cool it is and we'll wait for you for 5 minutes to get back here.

In the Bloom R18 version of the IDE we are introducing two more handy updates to this functionality.

Search in Apex classes and triggers

As promised - together with the release of the 'Find Usages' functionality, we are also adding this logic to the 'Field Usage Report' so you can easily find in what parts of your codebase certain fields are used. And again here - no more worries when you need to find where a field named like 'Name' or 'Account__c' is used - the IDE handles everything correctly so it will show you only that lines in the code where that 'Name' or 'Account__c' field from the needed object is used.

So both 'Apex classes' and 'Apex triggers' appear as the first-level groups in the results tree, with the grouping by a file name inside, while specific lines of code where a field is used are shown as the lowest-level items in the tree.

As always in the 'Field Usage Report' you can double-click on any Apex line in the results to get navigated to it in the Apex editor.

Managed packages support

The previous iteration of the 'Field Usage Report' was not very friendly to managed packages and objects or fields with namespaces, and it was showing 'No results' for such objects or fields.

It's not very good to ignore a significant part of objects and fields on your organizations, so we've convinced this report that it should show you this information 

Other Changes

At the same time, as always, together with implementing new abilities and functionalities in the IDE, we have prepared for you set of fixes and changes in the existing features to avoid some issues.

Let's start with the build process!

There is only one change here, however, it is a good starting point - our developers have solved the case when after a failed building of your Lightning files, there was a required pull during the next build of your changes. In this case, the IDE was asking to pull files that didn't contain any error(s) and could be built successfully previously. The reason for this was that these files had an updated, last modification date on your organization after that previous build failed, however, the IDE rolled-back the existing changes. So now this issue won't take your time for doing this additional pulling and won't stop you to updated your Aura files directly from TWS.

Also recently, we got several bug reports and were faced with a issue when there was an error when you opened some log files or were going to start debugging in the IDE. This was caused by a new structure and new set of parameters for some entities inside a log file. This came with the updates from Salesforce after they moved sandboxes to the Summer'18 version. We have handled this and now you can work on log files generated on your updated sandboxes as well as on log files from other environments.

While working on the sObject inspector to improve it, we have fixed some cases that were caused by the presence a namespace for your org. For example, there were some empty FLS settings for standard objects from such organizations, or some fields of custom objects were duplicated in the list. If you would have any other missed or improperly displayed elements, please let us know and we will handle all of them.

One more issue that we got from our users was a crash of TWS when running tests. This crash happened when there were some incorrect or expired credentials for your TWS project. Also, the workaround for this issue was to updated the login, password, and security token in the project, or re-authorize if you used OAuth. Beginning from The Welkin Suite Bloom R18, the crash won't occur anymore and, in addition, we have extended logging for such cases. However, keeping your credentials updated is always a good idea 

Also, there was a case when the IDE crashed during the creation of a project. To be more detailed, the crash occurred when loading the list of files which you can select to download to your new TWS project. The reason for this was an unhandled exception when running an internal query to the list of referenced packages files.

We will continue to make The Welkin Suite better and solve issues, and if you would be faced with anything that works incorrectly or has unexpected results - please let us know!

We are not promising that the next version of The Welkin Suite Bloom will be available soon, however, you can be sure that it will impress you - we are working on a set of really highly required features and the main one of them is full metadata support inside your TWS project!
Stay tuned for our updates and be ready to improve your Salesforce development and administering process even more with The Welkin Suite IDE!

Full list of changes

New Features:

• 'Find Usages' in Apex for variables, methods, classes, etc.
• Added the support for the Global Picklist Values metadata
• Added the support for the Custom Metadata - editing Custom Metadata objects
• Added the Custom Metadata Records Editor tool to the IDE
• Added the support for Dependent Picklists configuration in the sObjects Inspector
• Added Apex Classes and Triggers to the Field Usage Report
• Added visualization for fields that are required in an object definition or in a layout to the sObjects Inspector

Improvements:

• Implemented an ability to export data from the sObject FLS editor to a .csv file
• Added the support for objects and fields from a managed package to the Field Usage Report
• Added the Tracking Changes panel to the Declarative Development and Administering layout by default
• Modified default names for cloned fields in the sObject Fields editor

Fixes:

• Fixed the issue when there was a required pull after a failed building of Lightning components
• Fixed rare cases of crashes of the IDE when executing a test-run
• Fixed the error when opening a log file or when starting a debug session for a log file generated on sandboxes moved to Summer'18 Salesforce version
• Fixed the issue when FLS settings were absent for a standard object if the organization had a namespace prefix
• Fixed the issue when fields of a custom object were duplicated in the FLS sObject editor if the organization had a namespace prefix
• Fixed rare cases of the crash of the IDE when double clicked on a test/method in the Tests Results panel
• Fixed rare cases of the failed project creation due to the exception related to retrieving referenced packages files