looking to query the sfdc metadata and determine if there are any workflows, validation rules etc that are specifying a "null" record type

Question

There is a requirement where we need to know if there are any workflows, validation rules, code, process builders, etc that are specifying a "null" record type for any of the object in the org. We are looking to query sfdc metadata to determine if there are any workflows, validation rules, code, process builders, etc that are specifying a "null" record type.

The requirement arose from a particular situation. The situation is, We are using sfApex Tool for migration of data from from production to partial sandbox. There were records in the Source(prod) where fro many objects default record type is not set. sfApex tool does not allow records to be transferred with Null record types, so for those objects it assigns any random record type in the destination org.

So to handle this situation, we need to set default record types for these objects. If we simply set it, there might be situation of conflict where any configuration(workflows, validation rules, process builders) or code(Apex) is already creating records with null record type. Before we set the default record type for these objects, we want to know if there are any workflows, validation rules, code, process builders, etc that are specifying a "null" record.

Answer 1

You're going to need to pull your metadata down to an IDE, such as Visual Studio Code with the Salesforce Extension Pack, and review it there. You won't be able to achieve this with a query.

Each metadata entity (Apex code, Process Builder, Workflow Rule, etc) stores its logic differently and must be evaluated differently for this objective, which may also need further definition.

It's quite legal in Salesforce to simply not specify a Record Type when creating an object - you don't populate the RecordTypeId field, and the system will supply a default. One does not have to explicitly set it to null for this behavior to take place; it's implicit. Hence, identifying locations where a "null record type is specified" is likely to turn up very little. But note also that allowing this implicit behavior to take place is not wrong per se: in many cases it is in fact the correct behavior, since not all users have access to all Record Types and selecting the default one upon record creation is sensical.

On the one hand, this makes your task a little more challenging, because you're really going to need to hand-review every automation that creates a record if your true objective is to find locations where a Record Type is not explicitly specified.

On the other hand, this makes your task a little easier, because you can eliminate from review entire classes of metadata that cannot create a record at all. Validation Rules, for example, do not modify data in any way.

Answer 2

Going off what David said, the easier part is that it can limit how much you manually go through, but the important thing is you'll need some analysis in each type to figure out if there's action needed.

As mentioned, you want to see how the object is referenced in the different metadata types and search each. I'd be doing this in my IDE with all the metadata in question (in my case, IntelliJ/Illuminated Cloud but VS Code should be similar).

I'd look for references to the object as opposed to recordTypeId as David mentioned, it might not be explicitly set. Once you get results, you'll have to look more closely to see if they're creating the object as I believe that's the scenario you're looking for.

---

Quick Action

<targetObject>sobjectName</targetObject>

---

Process Builder/Flow

<object>sobjectName</object>

---

Apex

might be your toughest one as it's dependent on how you name variables, but you could just search for references to the object name and manually go through it. Not the best, but if you're confident you could also look to do

insert task

Assuming you might use variants of the variable name of taskList, tasksToInsert, etc.

Otherwise, since the goal is to filter the results best you can and not miss anything, the safer bet is to just do a search for the Object API name.

---

Workflow

You might be better off simply looking at this through the UI in the list view for all workflows related to the object in question. Otherwise, you'd be relying on naming convention to include the object name or hoping there's criteria. If there's criteria, this could be useful.

<field>sobjectName.