Common usage for describe method can be as follow:
Map<String, Schema.SObjectType> schemaMap = Schema.getGlobalDescribe(); Schema.SObjectType OppSchema = schemaMap.get('Opportunity'); map<String, Schema.SObjectField> OppfieldMap = OppSchema.getDescribe().fields.getMap(); for(String field: OppfieldMap.keySet()){ //Do something }
The customer develop customize sync process between Quote & Opportunity.
His process uses describe method to get all the Quote and Opportunity fields and synchronize any field which have the same API name.
This process start causing errors or unexpected behaviour after winter 18 release.
After investigating the issue, we found that the main change that break the process is that salesforce introduce/expose in Quote object the field ownerId, which is populated by the quote creator and cannot be updated.
Generally, quote is related to Opportunity in Master-Detail relation. In such case, normally the child (quote) doesn't have owner. The owner of the parent (opportunity) is also the owner of child (quote).
But seems SF might break this normal behaviour for Quote object. It is not documented in the release note, but it is probably related to the pilot Quotes Without Opportunities Pilot - Winter '18, which contains below feature and make sense to have the field ownerId in Quote.
1. Create new quotes without opportunities
2. Update or remove opportunities from existing quotes
3. Control access on old and new quotes
4. Change owner on old and new quotes
Anyway, back to the customize sync process. After winter 18, when running the sync process, if trying to sync the fields from Opportunity to Quote the process was failing with exception, as it try to update the opportunity owner to the quote owner, and the field is not writable.
If trying to sync the other direction - Quote to opportunity - the process success, but it wasn't the expected result - opportunity owner was override with the quote owner (which is the quote creator and is not always the same person).
As fix, we exclude hard-coded the field ownerId from the process. It solve the issue for now.
For future, their process does need to be amended to sync only explicit list of fields.
Some insights I took from this case:
1.should be careful when using describe methods and working with the entire fields. Even when retrieving the fields dynamically, it's recommended to limits the result with other setup -e.g. fieldSet, Custom Settings.... Actually, in many case you might use only the former setup (fieldSet, Custom Settings) to control the fields you need, instead of going over all object fields.
2.When working with standard Object should be carefull when override standard functionality.
You should use dynamic process, which allow you to have changes in future without changing the code, but must take under consideration also SF changes for their standard.
3.Run full tests after the release changes are in sandbox. Recommended full sandbox with integration. It not 100% insurance, but might help to detect regression issue in advance.