I'm in the middle of writing a Jenkinsfile so we can have one Jenkins job that handles multiple branches and multiple org configurations. For the multiple org configurations, I'm using the parallel mechanism so that a single code checkout gets deployed/tested using multiple orgs at the same time, with each org configured differently.

The most awkward org configuration is one where Platform Encryption is set up. The core recipe for this is available in this GitHub project wadewegner/sfdx-platformencryption. The specific part that is awkward for me is to turn on the encryption for the 50 or so fields that we want encrypted when the tests run.

What would be ideal is if someone has written an SFDX Plugin that looks something like this:

sfdx custom:object:field --object Contact --field Email --update --encrypted true

This signature is shamelessly based on sfdx shane:object:field, one of the many plugins shared at mshanemc/shane-sfdx-plugins.

Is such a plugin already written and posted somewhere? (Yes I could spend some time writing it myself, but I have plenty of customer-focussed work I should be doing instead.)


Just looked more carefully at sfdx shane:object:field and realized it writes a local field file rather than making a call to the org so probably not the right starting point.

1 Answer 1


Thanks to Shane McLaughlin for his comments on https://github.com/mshanemc/shane-sfdx-plugins/issues/9. That, plus having looked at the SFDX plugin APIs a bit more, suggests that SFDX isn't a good fit so I am going to abandon that approach.

Instead, I plan to use the financialforcedev/apex-mdapi that allows Apex code to modify the metadata such as field definitions. This way the code can be used both for setting up scratch orgs when run via sfdx force:apex:execute, and to set up customer orgs when run through a setup page.


The MDAPI approach has worked well with these gotchas along the way:

  • even though it is an update request, several properties are mandatory (and extra ones are mandatory for some field types) so it is necessary to read and then update - see the assignments below that represent the mandatory properties
  • when you see a complaint about a missing type, the property name to set is type__x not type
  • the update has to be broken up into requests of no more than 10 fields at a time
  • this particular change of making a field to encrypted is quite slow so the service.timeout_x = 120 * 1000; work-around is needed

The properties I needed to set were in each MetadataService.CustomField for the update were:

    r.type_x = e.type_x;
    r.fullName = e.fullName;
    r.label = e.label;
    r.length = e.length;
    r.visibleLines = e.visibleLines;
    r.encrypted = encrypted;

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.