Big Object field types workarounds

If you have taken a look at Big Objects, you will have noticed that we can only create fields of the following types (information valid for Winter 18 release):

• Text
• Number
• Datetime
• Lookup to Standard or Custom objects

Big Objects can be used for multiple purposes, but typically, archiving old records is one of the use cases. What can you do if you need to archive a custom object which has field types that are not supported, as for example picklist or master-detail? What if you want to create lookups to Big Objects? Read this post and you will find a solution.

1) Checkbox fields workaround:

You can create a text formula field in the source custom object, that converts the checkbox information to a text, in the next way: IF(IsProcessed__c == true, “true”, “false”). Then, you will be able to copy the result into a text field on the target Big Object.

Another option could be doing the same, but using a number formula field on the source custom object, and a number field on the destination Big Object. IF(IsProcessed__c == true, 1, 0):

2) Picklist workaround:

In the same way than with the checkbox field, You can create a text formula field in the source custom object, that converts the picklist information to a text. Then, you will be able to copy the result into a text field on the target Big Object.

3) Master-Detail workaround:

In this case, you can directly copy the Id into a lookup field on the target Big Object. You won’t have the particularities of master-detail fields in this case, but at least you will have them related to your Custom Objects and you will be able to implement missing functionality. Remember that Standard UI is not available for Big Objects, so, if you want to show a related list of the child Big Objects on the parent Custom Object, you will need to develop your own UI.

4) Lookups to Big Objects workaround:

Lookups can be created on Big Objects, but they can point only to Standard or Custom Objects. If you want to relate two Big Objects, there is a solution that you can adopt.

Remember that from API 40.0 indexes on Big Objects are compulsory. This index can be compound, of up to 5 fields, and it will be the primary key or unique identifier for the records on the database.

As the index identifies uniquely the records of the source Big Object, what we can do is to create fields on the target Big Object that reference the source Big Object index fields, as we know that the combination of those fields is going to be unique per record on the database.

Do you want to start using using Big Objects? Don’t wait more! They are GA from Winter 18 and you can start playing with them right now. If you need more field types to support your solution, here you have some workarounds that will help you.

If you want to know more about Big Objects, check this post I recently published, and also this fantastic post from Agustina García.