function readOnly(count){ }
Starting November 20, the site will be set to read-only. On December 4, 2023,
forum discussions will move to the Trailblazer Community.
+ Start a Discussion
hb.mambohb.mambo 

Updating Audit Fields

I have had the audit fields (created by, created dates, last modified by, etc) opened by sfdc, and need to see if there is a way to populate these via an update rather than an insert. Through the data loader, they are only available via insert. Is this a data loader limitation or a salesforce limitation? We also have DB Amp, and do not have access on an update either. Anyway around this?

Shashikant SharmaShashikant Sharma

These fields created by, created dates, last modified by, etc are only readonly so you can not update them.

 

created by, created dates fields  are only set when the record is created. These do not get change in further updated.

 

last modified by field is also not writable but it gets updated after each update. You can see this by updating any record by another user.

 

You can not update these fields from Apex, any API , Data loader or by anything.These are filled and contrlled by salesforce. That is the behaviour, If you want to call it limitation then it is salesforce limitation

hb.mambohb.mambo

If you open a case with salesforce, they will temporarily allow access to these audit fields. I have opened the case with salesforce, and they are in fact open to push data into, but only by insert.

Ankit AroraAnkit Arora

Yes Mambo, we can log a case for that and after we get notification from salesforce we are allowed to enter the data in these fields. But only for insert and not for update.

 

 

Thanks

Ankit Arora

Blog | Facebook | Blog Page

Bhawani SharmaBhawani Sharma

Hi Mambo,

 

This is because of, if you want to keep your data in salesforce from lagecy system and don't want to change any existing system information , you can do that with activating audit trail.

But after that your records becomes part your system and similar to other technology lastmodifieddate works as a system field and will not be available for manual change.

sfdcfoxsfdcfox

As a minor clarification/addendum, this is a salesforce.com-implemented limitation. There's nothing restricting the developers of salesforce.com (from a technological standpoint) of making the audit fields completely wide open. However, that would defeat the purpose of the audit fields. I've seen other requests like this, too, such as "disable audit field updates for administrators" or "disable audit field updates for minor updates." They are the way they are in order to help enforce data forensics capability (I believe this was a requirement for government contracts, and possibly a few laws). Also, they made this feature for importing legacy data, not just updating any record as you please. You'll have to accept that the fields are what they are, and they won't be changing anytime soon.

cmoynihancmoynihan

One of the biggest problems with this self-imposed limitation is when migrating legacy data.

 

I am in the middle of migrating our old support ticket system the Cases module, and trying to get the old data in there properly is nothing short of magic.

 

With Cases, you cannot import the Case Number (which makes NO sense at all) so you have to set the Case Number autonumber to your first record, and have dummy records for any missing number in the sequence or the Case Number becomes off.

 

Once you import however, you can't update the existing records. In our case, I am migrating the data a bit early to save on downtime, and then updating only the changed records on go-live day. Except I can't update Last Modified By and Date, or Closed Date (if the Case was closed since).

 

To make it work, I have to delete any Case that was modified, then one at a time set the autonumber to the right Case Number and do an insert for that Case. Rinse and repeat for any changed Case.

 

Tedious and ridiculous. If I am "compromising" my audit fields to begin with, who cares if I can update them afterwards?

 

Of course my particular problem would be fixed if I could import the Case Number. But I can see migration situations where even if you could just reimport, if there are any kind of relationship to those records, their Id changes when you delete and recreate them again.

 

As great as SF can be sometimes, it can pretty frustrating and bad as well.

sfdcfoxsfdcfox

I personally agree with your argument completely. Administrators sometimes do need to make invisible edits, and consultants and data migrators would have a far easier time if they could edit any data at-will. The system isn't going to blow up if the Created By and Created Date fields are modified by a responsible person, so there shouldn't be any problem at all with this. At this point, though, I suppose they'd have to figure out how to implement it "sanely", as you wouldn't want to accidentally release a version where any user can bypass the fields.

gitguygitguy

Supposedly this feature has been enabled for our org, but how can I be certain?  Whenever I try insert a record into Account with dataloader I get the error:

 

INVALID_FIELD_FOR_INSERT_UPDATE:Unable to create/update fields: CreatedDate. Please check the security settings of this field and verify that it is read/write for your profile or permission set.
Error fields: CreatedDate 

 

After the feature is enabled,is there something else admin are supposed to do or is it just supposed to work?

W Chad SmithW Chad Smith

That's kinda' interesting, I am seeing the same thing right now.  Using an insert and all and it's not working.  I'm using PE with API enabled, not sure why that would make a difference, however.

ArpitaArpita

How to edit the Craeted Date ....

Ricky ThedaRicky Theda
Hi cmoynihan,
currently i'm facing a same problem with you, I must to migrating my case record. I've my audit field enabled by salesforce support but when I'm trying to importing case records with data loader, I cannot mapping the case number field because the field is not available.
Have you facing this problem? and one more thing may I ask your email?
osizeosize
For a System Administrator to enable the feature they can follow the click-path below:
Setup -> Customize -> User Interface -> Enable "Set Audit Fields upon Record Creation" and "Update Records with Inactive Owners" User Permissions
 
After enabling this organization wide permission, you need to grant to the user the profile permissions:
Set Audit Fields upon Record Creation - in order to allow the user to Set audit fields, such as Created By and Last Modified By, when you create a record (API only i.e Importing Tools) through Data Loader.
Update Records with Inactive Owners - in order to allow the user to Update owner and sharing-based fields on records with inactive owners.
 
Salesforce Support can turn on the Create Audit Fields feature for your organization in the event it's not correctly enabled.
 
While this feature is generally low risk, we recommend taking the time to review as much documentation as possible prior to requesting it be enabled.
 
You can also refer to the link below for more information:
 
https://help.salesforce.com/apex/HTViewSolution?urlname=Enabling-Create-Audit-Fields&language=en_US
eyewellseeyewellse
Note that not all objects are supported. At the moment Email Message is an example of an object which cannot be enabled for "Set Audit Fields".
See these considerations: https://help.salesforce.com/articleView?id=Considerations-before-having-Create-Audit-Fields-enabled&language=en_US&type=1