4

SystemModstamp is an Audit field and is not set-able even if you get Salesforce to allow you to access Audit fields. See here for more info: http://www.salesforce.com/us/developer/docs/api/Content/system_fields.htm


2

Here is the cause. https://help.salesforce.com/apex/HTViewSolution?id=000005055&language=en_US Once you disable Shared Activities (the ability to have multiple contacts on activities), it works.


2

The fields can be editable when inserting records, you need to raise a case with SalesForce to request edit access on the CreatedBy, CreatedDate, LastModifiedBy and LastModifiedDate fields. This will allow you to edit the fields to whatever values you want when inserting the records. Using this you could potentially create a new record which clones the old ...


2

The system currently ignores the milliseconds for the purposes of considering two values equal. Here's some code you can run in your org to prove it to yourself: User u = [SELECT SystemModStamp FROM User ORDER BY SystemModStamp DESC LIMIT 1]; DateTime dt = u.SystemModStamp; // add 900 milliseconds dt = DateTime.newInstanceGMT( dt.dateGMT(), Time....


1

Changes in formula fields will never be reflected in systemodstamp because formula fields don't really hold data. Instead they are evaluated when the record is being read. However, changes to Rollup Summary Fields should be reflected in the systemmodstamp of their record. And even if for some reason they're not, you could write logic to be driven by a ...


1

You can use the Flow to update another field, that then triggers the Process Builder that will run in System and modify the record the Running User is unable to modify. The only other option would be to possibly use an Apex plugin. There is no way to make your Visual Flow run as System.


1

SystemModStamp is strictly read-only. Not only is it updated when a user updates the record, but also when automated system processes update the record. Because of this behavior, it creates a difference in stored value where ‘LastModifiedDate <= SystemModStamp’ but never ‘LastModifiedDate > SystemModStamp’. You can use SystemModStamp in your SOQL ...


1

The SystemModStamp will always be set. If you requery the object in your test class it should get you the SystemModStamp: Account a = new Account(); a.Name = 'name'; insert a; system.debug(a.systemModStamp); system.debug([select Id, SystemModStamp From Account Where Id = :a.Id]); returned: |DEBUG|null |DEBUG|(Account:{SystemModstamp=2014-04-03 19:08:12, ...


1

You can setup a debug log for the integration user. This should give you insight on any DML operation that is happening as part of some indirect process.


1

What is the logic that references OpportunityHistory? OpportunityHistory is read only and is system generated based on criteria so you cannot create it in tests nor can you update an opportunity in your tests then reference the history as the records are only created upon a database commit. I've ran into this issue before using ActivityHistory and had ...


1

The systemModified time stamps are not allowed to overwrite .Those are not writable field .Testing may require with reducing the value for testing for small interval. Example if your test scenario is with 30 days old change in code for 2 days old date and test it and after test update again in code for 30 days old .


Only top voted, non community-wiki answers of a minimum length are eligible