Blaze R12 with Field Usage Report, Custom Metadata Types, OAuth and other improvements

It is time to welcome one more big "cumulative" update of The Welkin Suite for Mac - yes, today we are rolling out great new version of the IDE with some really important and helpful changes. It is even hard to say if the focus is on point-n-click Salesforce development, taking into account a set of new features for sObjects Inspector and absolutely awesome Field Usage Report, or if it is geared towards those who write code with Custom Metadata support and Find Usages for Apex.

But who really cares about defining a "theme" for the new version of the IDE if there are so many great features? Btw, 5 minutes of your time spent on reading release these notes will make your life much easier right from the first launch of the Blaze R12 as you'll know where to look for all the new features (and you are going to want to look for them )!

Field Usage Report

How many times in the last month or two have you been facing a situation when you've had to understand how this or that field influences your organization? What impact does it have? Is it safe to remove it? Or just trying to onboard into an existing organization that has a lot of business logic already in place? Something is telling us that the smile on your face that has just appeared is not the happiest smile, isn't it? 

Looking for field usages in the organization is a complex process that usually ends up in 10+ tabs being opened in your browser, a lot of wasted time and, still sometimes something might be lost. The reason why something might get lost is not because of us, developers, who are not paying enough attention to what we are doing, but because there are so many different (and not always obvious) places where a certain field might be used and also because there is no good tool to help you with all of this. Oops, there WAS no good tool to help you in that - now you have the built-in Field Usage Report tool in The Welkin Suite!

You might think about a hardcore way of downloading all metadata files from your organization and using the regular Search options to help you? Of course, we'll forget about understanding where any field named 'Name', 'Id', 'CreatedDate', etc. is being used, but it work in all other cases, right? Well, it might, but there are a lot of weird situations, especially around standard objects and fields, when the field is somehow referenced, but not by its API Name - have you noticed this? You're lucky 

The Welkin Suite's Field Usage Report does its job in a much more intelligent way - we are analyzing your local files according to a carefully, crafter set of rules for each type of metadata and for each place where a field might get used. This approach ensures that we are "bulletproof sure" in the results we show you, ensuring that you won't see something that is not true, or that you won't miss anything important. As a downside of this approach - it will take us some time to cover all the areas, where fields might get used, but we are sure that right now you'll have a great assistant for 90+% of the cases!

Field Usage Report is available for you in literally any place where a field is displayed:

• In the 'Admin Panel' - in a context menu for a field or in the toolbar when a field is selected
• In the 'Schema Explorer' - in a context menu for a field using the 'Open Field Usage Report' button
• In the sObjects Inspector's Fields tab - in the toolbar
• In the sObjects FLS tab - in a context menu for a field

When you open the Field Usage Report for any field - the first screen you'll notice is the overview information of where the IDE is looking for fields (you can see this in the screenshot at the beginning of this section). With this information, you will be aware of what information is taken into account when the IDE returns you some results. The list of currently supported locations is:

• Apex - both Apex Classes and Triggers are included, so all field references in your code will be found;
• Approval Processes - in all possible actions, emails, criteria, and page fields taking into account expressions, relations, macro usages. The only limitation is that the IDE does not check plain text versions of Email templates, that might be used as a part of Approval Process itself or as Email Alerts in some actions;
• Email Templates - while emails are used in approval processes and in workflows, the IDE will list them separately as well, but with the same limitation - without searching in a plain text version;
• Layouts - of course, the IDE will check if a field is included into any layout, but it also will find a field if it is present in any Related List on other layouts (however, this can have some possible limitations for standard objects);
• sObjects - virtually we will scan every part of an sObject, excluding web links: list views, compact layouts, sets of fields, formula fields, default values, rollup summary fields, filters in lookups, dependent picklists;
• Validation Rules - in both Error Condition Formula and in the Error Location field;
• Workflows - in the same way as in the Approval Processes, the IDE will look for a field usage, everywhere in the Workflow, where plain text email templates are the only exception.

In the left part of the Field Usage Report, the IDE will show you a tree view of all places where the field is used. By default the list has the 'Object view' - all locations (except Email Templates and Apex Classes/Triggers) are shown under corresponding objects, where they are defined. In the 'Object view' it is very easy to detect logical dependencies between objects or analyze how exactly this or that field is used in different objects. If you'd like to look from another perspective, let's say - analyzing the impact of a field on some business logic or identify something like a character of a field (if it's an 'output' field that's only used for displaying something or if it's an 'input' field, that is used in lots of formulas and affect calculations and processes), you can switch to the 'Type view' using the corresponding toggle button in the toolbar. In the 'Type view,' the location type (e.g. approval process, validation rule, workflow, etc.) will be shown as a first level in the tree, while objects and further details will take place on lower levels of the tree.

Let's go into more details through the locations that The Welkin Suite uses to show you the Field Usage information.

Approval Processes

In the case, when a field is used in one or multiple approval processes - you will see 'Salesforce approval processes icon for the Field Usage Report Approval Processes' node in the tree on the left side of the report. In the 'Object view', you will see the list of approval processes where the field is used as child items, while in the 'Type view' you will see the list of sObjects as child items and approval processes on the second level.

All occurrences within the approval process are grouped into the following categories (child nodes):

• Entry Criteria - child nodes for this group will be different criteria where the field is used.
• Final Approval Actions - child nodes for this group will be 'Field Update' or 'Email Alert' actions included into the corresponding group of actions in your approval process.
  • For field updates, the IDE looks in both the field, that will be updated, and in the formula.
  • For email alerts, the IDE looks in the 'Recipients' setting and in the HTML version of a template, while ignoring a plain text version of a template.
• Final Rejection Actions - the same as above.
• Initial Submission Actions - the same as above.
• Recall Actions - the same as above.
• Step Approval Actions - the same as above. But please note that the actions are not grouped by steps here - all approval actions from all steps are shown as child nodes for this group.
• Step Rejection Actions - the same as above.
• Approval Page Fields - the same as above.

As you select any 'occurrence' (a last item in the tree hierarchy) in the left part of the report - you will see its details on the right part of the screen. Usually, TWS gets these details directly from an XML representation of an item, so you will be able to see all your needed information. As well as double-clicking on any occurrence or selecting any of them and clicking on the 'Open in editor' button - the IDE will navigate you directly to a file and line where this usage was found, whether it field update, email template, criteria, or anything else.

Email Templates

When your field is used in one or more email templates - the Field Usage Report will show you all of them under the 'Salesforce email template icon for the Field Usage Report Email Templates' node.

Information about email templates is the simplest across the locations where the IDE looks for field usages, so there is not so much to say about it, to be honest.

• Each occurrence of a search field will be shown as an item within the 'Email Templates' node.
• Right now only HTML versions are scanned.
• The 'Open in editor' command will open a corresponding *.email file direction a line where the field is referenced.
• Email templates are always shown separately, no matter if you're in the 'Object view' or in the 'Type view'.

Layouts

One of the easiest locations to check yourself is to detect if the field is used in the layouts, however, this would true only when we do not take into account the related lists. This is why you can see the 'Salesforce sObject layout icon for the Field Usage Report Layouts' node, with the following details:

• In the 'Object view', 'Layouts' will be present as child nodes for corresponding objects;
• Inside the 'Layouts' node you will find a list of Layouts where your field is used;
• Each layout in the list contains the following sub-items:
  • Name of the section, where the field is used on the selected layout;
  • 'Layout Related Lists' item, that shows you that the field is included as a displayed column into a related list on the selected layout;

As usual, double-clicking on the last item in the tree hierarchy will teleport you, into the editor, directly to a line in a file, where the field is used.

If you'd select any layout in the tree on the left side of the report - on the right (details) sided you will see the full list of fields that are shown (and not shown) on the layout, their attributes and in what section they are shown. Exactly how you'd see this in the Admin Panel, with the only difference that the search field will be highlighted in bold.

Validation Rules

In the 'Object view', the Field Usage Report shows 'Salesforce validation rules icon for the Field Usage Report Validation Rules' as a child node for sObjects where they are defined, so you can quickly identify if, let's say, the fields from your Account object are used in any validations in the Contact object.

Once you expand the 'Validation Rules' node, you will see a list of validations where a field is used (within an object), and for each of them you can get one or both of these occurrences:

• 'Error Condition Formula' means that a search field is used as a part of a formula;
• 'Error Location' means that a validation error message is displayed near a search field.

Once you select any of these two items - you will see the details of a validation rule on the right side of the report.

Workflows

Even with the Process Builder in place, Workflow Rules are essential for many organizations, since a lot of business processes automation can be done in a good old way. Taking this into account, searching across workflows is an absolute must-have, so The Welkin Suite not only looks for field usages in workflows, but also provides you with the results in a very handy and intuitive way.

Under the 'Salesforce workflow rules icon for the Field Usage Report Workflow Rules' node, you will find a list of workflows where a field is used, while for each workflow you can find these sub-items:

• Alerts - will show you all Email Alert actions, where a search field is used in an HTML template or as a 'Recipients' field.
• Condition - will show you a formula that is used as a condition for entering that workflow, if a search field is referenced in an expression.
• Field Updates - shows a list of Field Update actions, where a search field is an updated field.
• Field Updates Formulas - includes a list of Field Update actions, where a search field is referenced in a formula used for a new value for a field.

Don't forget that you can double-click on any 'last' item in the report tree and the IDE will navigate you directly to the line in a corresponding XML (or any other) file, where an item is defined.

sObjects

Whenever your search if a field is used in any other field in your organization - The Welkin Suite will handle this situation and it will highlight you such cases.

There's not so much to explain, as it is pretty simple and clear, but anyway:

• If your field is used in any expression in a formula field or as a default value.
• If a field is used in a rollup summary field.
• If it's used as an expression within a lookup filter on the same or another sObject.
• If a search field is a picklist and if it is controlling or controlled by any other picklist

When you'd double-click on any field in the Field Usage Report, the IDE will open its built-in sObjects inspector where you'll be able to modify a field using plain XML or a GUI editor.

To finalize the picture of your sObjects, the Field Usage Report also shows all occurrences of your search field in Compact Layouts and Field Sets, that are displayed under the corresponding nodes.

When you select a compact layout or a field set where a field is used - the IDE will show some basic details of the item on the right side of the report, while double-clicking on a compact layout or field set will navigate you to a corresponding XML file.

List Views

While being a part of sObjects from both technical and logical side - we'll describe 'Salesforce list view icon for the Field Usage Report List Views' separately, as there's a bit more information about List Views, compared to fields, for example.

Once you expand the 'List Views' node, you will see the list views associated with a certain object, that use a search field in one of two ways:

• 'List view column' - when the field is shown as a List View column.
• 'List view filter' - when the field is referenced in a filter expression, used for a certain List View.

Apex Classes and Triggers

Both 'Apex classes' and 'Apex triggers' appear as the first-level groups in the results tree, with 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.

Custom Metadata - Editing of Objects and Records

Custom Metadata is an awesome way to customize and configure your Salesforce application. Our team is working right now on implementing support for all metadata types that are available in Salesforce, However, we'd want to push forward the support for Custom Metadata a bit ahead of schedule, and add a bit more functionality - not just plain XML editor. If you haven't yet familiarized yourself with Cusutom Metadata Type - check out this Trailhead module. By the way - completing the module using The Welkin Suite is a great option to get to know both Custom Metadata Types and how they are supported in the IDE.

When you are going to start your work with Custom Metadata Types you need to add them to your project - you'll be able to do this during a project creation process or later in the 'Project Metadata Components' wizard that is available in a project's context menu in the Solution pad. 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

When you open any Custom Metadata Type definition file you will see the same editor as you did for regular sObjects. Of course, you can add new ones or change existing fields by using the GUI part of the editor or you can do all your modification in the XML definition of the Custom Metadata object - you're can choose whatever is quicker and more easy for you.

Also, Custom Metadata Types are viewable in the Schema Explorer and Admin Panel, so you can locate them almost everywhere.

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 application menu using the Tools → Custom Metadata Editor command.

On the left side of the Custom Metadata Records Editor, you will notice an approach that you are already used to, 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 notice a table that has the records which are available locally in your project. You can change existing records by double-clicking on any field and modifying 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
• 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
• Set original value - reverts back to the original value of a cell if you have modified it
• Set value to Null - if a selected field is Nilable, this option will set its value for the record to Null
  
  

As you noticed on the screenshots above - the modified cell will be highlighted with a different background. Plus, You will notice a change indicator in the list of Custom Metadata on the left side - in the case that any record has been changed or added for some certain Custom Metadata object, there will be a visual marker near its name in the list so you do not miss what was changed.

OAuth Support

The Welkin Suite Blaze R12 - this is the time to move OAuth authentication to the Mac version of the IDE!

There a lot of reasons for using this feature for your TWS projects. For example, in this case, your Salesforce credentials are not stored in a project file and you can share a project without sharing your login and password or create TWS projects related to organizations that have 2 factor authentication.

So now on, when you create a new project in the IDE, you are able to select if you want to specify your login, password, and security token (if this is necessary) or you select the OAuth option for authorization and login into your organization via a browser. In the second case, after you would select this option, the credentials fields will disappear and after clicking the 'Next' button you will be redirected to a browser to Salesforce login.

When the authentication process is successfully finished, you will be asked to allow access for The Welkin Suite to your org. We want to draw your attention that this is actually during only the first connection to your organization using OAuth authentication. After you would click 'Allow', you will be back to the IDE and you can start work on your new project.

In the case, if you need to refresh your OAuth credentials, for example when the current ones would be expired, you can use the 'Re-authorize with OAuth authentication' command in the context menu of your project in the Solution Explorer or in the menu Project.

Advanced Required fields indication in sObjects Inspector

Another change in the sObjects Inspector that is aimed to help you answer the simple question "Is this field required?" in a few blinks of the eye without losing any details. And what we mean by 'without losing any details' is that we are taking into account the information about your page layouts, and if a field is needed there too.

From this point on you will have 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, it is important to notice that 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.

Picklist Valuesets in sObject Inspector

Global Value Sets (or Picklist Value Sets as shown in the org UI) are great ways to save developers and admins some very valuable 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 off, 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.

Then when you get your Global Value Sets in the project, you have the ability to edit them as regular XML files that are located in the 'globalValueSets' folder by default.

Plus this - you will also see the proper information about your picklist fields that are using Global Value Sets right from the sObjects Inspector:

In the cases that you would need to modify some values in the value set - you can press the '...' button to edit the Picklist Value Set. Please be mindful 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.

Find Usages in Apex

There is no longer any need to use the 'Find in files' functionality in the IDE to find where else your Apex variable, class, method, etc. is being used. This is because there is already an option to do this in a better way, straight from the editor!

You can execute this search in a few ways:

• With a hotkey - 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'

What do we mean by that term "item" above? We mean this is a variable, class name, interface name, method name, constructor name.

The results of the 'Find Usages' action will pop up in a 'Search Results' panel, where you will see all references to the item you've looked for, grouped by files.

In each results entry you will find:

• Project and filename where the occurrence was found
• The location within a file in the 'File' 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.

Other Changes

We have added the Tracking Changes pad to the default set of panels in the Administering layout. Also, if you have any other preferable pads which you would want to see in the provided layouts and which you use in your every-day flow, you can contact us about this and we will add them (or remove unnecessary ones) to the default ones.

Have you tried the 'Clone Fields' functionality in TWS already? What do you think about this?) We have also done some UX improvement for this process - this is related to names of your 'new' fields. Previously you got predefined names for your cloned fields something like 'FIELDNAME_Clone1__c', 'FIELDNAME_Clone2__c' and we now have guessed that each time you were having to go and change these names, and at the very least you had to remove the  'CloneX' suffix. So what have we done to make this better? You now won't get the suffix and you will instead get an additional part like '1', '2' and so on, but only in the case if a field with the same name already exists in your object. We believe that this approach would be more convenient and usual for you, like in Windows Explorer!

Our developers have found a way to solve the issue when after a failed building your Lighting files , and you were going to build your new changes again, and then there was a required pull from Salesforce for some of these files. This was caused by a refreshed Last Modification date value for the files that could be built successfully previous, while some other files contained some error(s) which stopped updating. So now you don't need to make that additional pull, and you can send your changes to your organization when it is necessary.

New updates from Salesforce are coming and some of them are related to the debug log files. For example, some entries have another structure or an updated set of parameters. So if you are working on a sandbox that was already moved to the Summer'18 Salesforce version - now you are able to open your log files and debug them without any errors. And no worries - TWS supports the updated log files, as well as the logs from environments that have not been moved to the updated version.

Several more fixes are dedicated to sObject FLS inspector. Previously there could be missed FLS settings for standard objects or fields of your custom object could be duplicated in the FLS editor if the related organization had a namespace prefix. As you can guess, beginning from this version of TWS - you will get all the appropriate data about your field level security settings without any being missed or duplicated elements!

Also, in The Welkin Suite Blaze R12, we have fixed crashes of the IDE. You could be faced with these crashes when:

• running tests: there were two reasons for these crashes; one could occur when there were improper or expired credentials in your TWS project - for this there was a workaround when you could update your creds in a project and continue working on it without this issue, however, now this won't lead to any crashing of the IDE; another reason for this could be a corrupted test-cache file, and our developers solve this issue too;
• the IDE was getting tests results from your organization: this also was related to a corrupted test-cache xml file;
• closing an Apex class: this crash could happen when you closed a class where the code-map with the list of its members was empty.

Full list of changes

New Features:

• 'Find Usages' in Apex for variables, methods, classes, etc.
• Implemented the Field Usage Report for dependencies and usage analysis
• Added an ability to use OAuth authentication for TWS project creation
  
• Added the support for the Global Picklist Valueset metadata
• Added the support for the Custom Metadata - editing Custom Metadata objects
• Added the Custom Metadata Records Editor tool to the IDE
• Added visualization for fields that are required in an object definition or in a layout to the sObjects Inspector

Improvements:

• Added an ability to export/import sObject Tree API data for Salesforce project
• 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 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 rare cases of crashes of the IDE when executing a test-run
• Fixed rare cases of crashes of the IDE when retrieving tests results data
• Fixed rare cases of crashes of the IDE when closing a class file
• Fixed the issue when the 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