2

There is a particular scenario where an auto-number field had to be disabled during a certain operation. This example on salesforce is exactly similar to my restore requirement. For this, the field should be converted from auto-number to a text field and then operated. This is done using Metadata API.

However, there seems to be a small issue here. If the field is neither createable nor updateable, the field value cannot be changed. This was double checked with the describesobjectresult calls.

Can this restriction be worked around?

To give an example, a custom object under the name testautonumber__c, the properties of the object are:

FieldName   IsCreateable    IsUpdateable    SoapType    FieldType   IsAutoNumber
Id  FALSE   FALSE   ID  id  FALSE
OwnerId TRUE    TRUE    ID  reference   FALSE
IsDeleted   FALSE   FALSE   _boolean    _boolean    FALSE
Name    FALSE   FALSE   string  string  TRUE
CreatedDate FALSE   FALSE   dateTime    datetime    FALSE
CreatedById FALSE   FALSE   ID  reference   FALSE
LastModifiedDate    FALSE   FALSE   dateTime    datetime    FALSE
LastModifiedById    FALSE   FALSE   ID  reference   FALSE
SystemModstamp  FALSE   FALSE   dateTime    datetime    FALSE
LastViewedDate  FALSE   FALSE   dateTime    datetime    FALSE
LastReferencedDate  FALSE   FALSE   dateTime    datetime    FALSE
text__c TRUE    TRUE    string  textarea    FALSE
**auto__c   FALSE   FALSE   string  string  TRUE**

The field auto__c had to be changed to both updateable and createable. I think this would clear up the whole requirement. Before restoring the object testautonumber__c,

  1. All the autonumber fields had to be converted to the string type and made updateable and createable (?) to accommodate the data

  2. Create/Update the records to the object with the data

  3. Undo the changes in step 1

  • 2
    Is the Auto Number field in question a custom, standard, or managed package field? – David Reed Jan 29 '18 at 16:55
  • Could be any object. There might be a few restrictions on standard object field but for making this work, this can be assumed as a custom object. – dmachop Jan 29 '18 at 19:52
  • Can you give an example of an Auto Number field on a custom object that cannot be made updateable using the procedure you have linked? I have used that workflow with success. Of course, it does not work with standard fields or managed fields. – David Reed Jan 29 '18 at 20:12
1

For Auto Number fields on a custom object in your organization, changing the field type from Auto Number to Text results in the field becoming updateable and createable simply because those traits are true for text fields and false for AutoNumber fields. You can do this conversion using the Metadata API or simply in the user interface. You're then able to update, or restore from backup, the contents of the text fields, before changing their types back to Auto Number, as described in the linked Salesforce documentation.

This approach does not work on standard fields or on managed package fields, whose types you cannot change. It's not possible to make those fields writeable for a restore operation.

If you must be able to restore values of those standard or managed fields, what you can do is create a couple of new fields to "shadow" it and provide backup and restore functionality.

Say the standard field is just called AutoNumber. Create a new custom Text field, for example Backup_Auto_Number__c. You'll use an after insert trigger or a workflow rule to copy the value of the real auto number field into the backup field. Then, create a new formula field, say Display_Auto_Number__c, with a formula something like this:

IF(NOT(ISBLANK(Backup_Auto_Number__c)), Backup_Auto_Number__c, AutoNumber)

Hide both the original AutoNumber and the Backup_Auto_Number__c fields from the layout and from reporting, and instruct all your users to make use of Display_Auto_Number__c.

Your backup and restore solution can then write data into the backup fields and have it displayed normally, while Salesforce continues to generate and populate new auto number values for newly created records.

  • By the solution given for standard/managed package fields, I guess there isn't any straight forward way to do this. This would mean that the shadow copy field will be present and when someone uses describes, there would be two additional fields along with the auto number fields and will have to live with that. This should suffice for my case though. – dmachop Jan 29 '18 at 21:19
  • @dmachop, that is correct. There is no good solution for standard and managed fields. That's just a limitation of the Salesforce platform. – David Reed Jan 29 '18 at 21:21

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.