Can existing formulas that reference encrypted fields be structured to work with or without Shield Platform Encryption?

Question

We have a customer who wants to use Shield Platform Encryption but that has the constraint that you Can't reference encrypted fields in Formula Field Types with these alternatives suggested:

1. Use WF field to set a field instead of a formula.
2. Build the same rule programmatically in APEX, store in a custom Text field and apply encryption on it.
3. Alternatively, if the formula is used to concatenate text to be merged into a VF page, concatenate the encrypted fields in the controller instead, in runtime, vs storing it in a field.
4. Limited support in Winter’17 (safe harbor).

The problem though is that we have such formula fields in a managed package and so cannot change their field type. Further we have multiple customers using those fields... I'm hoping (but fearing it won't be possible) for a solution that doesn't break the existing customers; the formula being blank for customers that turn on Shield Platform Encryption would be fine because we could set them up with one of the work arounds.

Something like being able to reference a field by a name obtained from a custom setting (a dynamic rather than static reference) would work but I don't think any such mechanism exists. Or perhaps there is no getting away from changing the formula to point to a trigger-updated non-encrypted field that programmatically checks whether encryption is on and if so leaves itself blank else copies the value.

Suggestions?

Answer 1

Not great, but the solution I'm going with is to add a couple of Contact fields populated by a Contact before trigger (and with a batchable to update existing orgs):

Boolean isFirstNameEncrypted = Contact.FirstName.getDescribe().isEncrypted();
Boolean isLastNameEncrypted = Contact.LastName.getDescribe().isEncrypted();
for (Contact c : Trigger.new) {
    // Using X instead of PE's * as this is different
    c.FirstNameCopy__c = isFirstNameEncrypted ? 'XXXXXX' : c.FirstName;
    c.LastNameCopy__c = isLastNameEncrypted ? 'XXXXXXXXXXXX' : c.LastName;
}

with the formulas changed to reference these so the code will deploy in a Shield Platform Encryption org.

The aim is to keep existing customer logic working unchanged. Unlike genuine encrypted fields, the masked values will always appear whether the User has "View Encrypted Data" rights or not in an org that has the fields encrypted.