Working with Salesforce Record Types and Offline Mobile Apps

Due to the fact that Salesforce record type IDs can vary between instances, it’s an important consideration to understand the effect of this on your design, development effort, and the potential failures once the app moves to production. As always with MobileCaddy, our aim is to remove this consideration to allow for more rapid and robust mobile apps.

salesforce-record-types

Salesforce record types

For nearly every object in Salesforce (both standard and custom), you can create multiple record types of the same object. This allows separation of ‘types’ of records. For example, if we had a custom object for ‘assets’ (so Asset__c) we may want to store types of these assets that have shared, similar, and distinctively different attributes.

There’s an excellent video by CertifiedOnDemand¬†which explains the concepts regarding why you would want to use record types, which I’ll refer to here, as our purpose is to look at the implications for our particular use case (here are some Salesforce tips and tricks on record types as well).

To take the example of an asset and use it to explore this further, we could then have ‘vehicle’ and ‘property’.

The shared attributes would be data such as:

  1. Purchased Date

  2. Cost

Our similar attributes might be:

  1. Write down time period (where we may restrict certain picklist values, such as a longer time frame may be available for a property versus a vehicle)

Our specific attributes may be:

  1. Address (for the property)

  2. Vehicle Registration (for the vehicle)

So to handle all the above, we would take our Asset__c object and create two record types. This is really easy to do and will allow us to have different picklist values and page layouts.

Each of these record types will have a separate 15/18 character Salesforce ID (and will effectively become a lookup from the asset records here to the record types). These IDs will be assigned through the standard Salesforce UI when the user creates or updates. Other than specifying the record types, we wouldn’t need to think much more about the solution.

Now we have a rough example, let’s explore the potential issue

Our issues can arise if we are to create, or potentially update (perhaps by changing record types), from the mobile application and we are storing the data locally to create an offline record, or in the cases where we want to change an existing type.

The issue surfaces when we’re doing our record types configuration (such as the creation of the record types) within a sandbox environment. The IDs that are created for ‘vehicle’ and ‘asset’ may well be different when we deploy these across to our production instance.

Record Type IDs are not necessarily the same values across production and sandbox instances.

What this will mean in practice is that as we’ve had to ask our developer to specify these record types in our app logic, once this app is deployed these record type IDs will not be correct, and we’ll consequently encounter record failures.

At this stage, the solution would be to do something like query the platform for the record type IDs and store these with a static value (such as record type name), and then do some juggling with the code to allow for the potential change of IDs from sandbox to production. The results are far more effort and a high potential for errors.

Doing things the MobileCaddy way

We believe that only the paranoid apps survive, and we want to assume these record type IDs will be different. But we also believe in rapid development. Therefore, we take care of this for the developer by allowing them to use a name in their code with no extra effort, while MobileCaddy keeps the IDs between boxes all up to date. We call this ‘mobile record types’.

The only work to be undertaken is to mobilise an object with a few point-and-clicks, and everything else takes care of itself. The record type IDs will update seamlessly when moving from instance to instance, and give the architect confidence that the final app will perform in whichever instance it’s then deployed and run against. What follows are easy offline record types and no concerns for any instance to instance migration.

Conclusion

This means, from both a design and an effort perspective, we can essentially treat record types as we would on the platform even for fully offline mobile apps.

In my next article we’ll take a detailed look at how, with MobileCaddy, the concept of record types can be taken even further for mobile to create separate tables, to speed up our synchronisation by reducing the number of fields while also making it easier for developers.

 

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

Scroll to Top