• cduncan
  • NEWBIE
  • 0 Points
  • Member since 2015


  • Chatter
    Feed
  • 0
    Best Answers
  • 0
    Likes Received
  • 0
    Likes Given
  • 2
    Questions
  • 3
    Replies
I noticed that the "Priority" default value specified in an Email-to-Case entry will overwrite values set in a "before" Flow, but it will be overwritten by an "after" Flow. (I have not tested triggers, but I imagine the result is similar.) The documentation at the link below does not specify where Email Services fall in the order of execution, so when does that processing happen?

https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_triggers_order_of_execution.htm

The REST API documentation states that you can use the Salesforce record ID as an external ID for upserting data.

This example uses the POST method as a special case to insert a record where the Id field is treated as the external ID. Because the value of Id is null, it’s omitted from the request. This pattern is useful when you’re writing code to upsert multiple records by different external IDs and you don’t want to request a separate resource. POST using Id is available in API version 37.0 and later.
https://developer.salesforce.com/docs/atlas.en-us.api_rest.meta/api_rest/dome_upsert.htm

How is this any benefit? Upsert calls with a true external ID all use the PATCH method, but using a Salesforce ID requires POST for new records and PATCH for updating records. With a Salesforce ID, you cannot PATCH a new record, and you cannot POST to an existing record, and the /Id/ part of the path appears to be redundant and unnecessary. How is this pattern actually useful?

The REST API documentation states that you can use the Salesforce record ID as an external ID for upserting data.

This example uses the POST method as a special case to insert a record where the Id field is treated as the external ID. Because the value of Id is null, it’s omitted from the request. This pattern is useful when you’re writing code to upsert multiple records by different external IDs and you don’t want to request a separate resource. POST using Id is available in API version 37.0 and later.
https://developer.salesforce.com/docs/atlas.en-us.api_rest.meta/api_rest/dome_upsert.htm

How is this any benefit? Upsert calls with a true external ID all use the PATCH method, but using a Salesforce ID requires POST for new records and PATCH for updating records. With a Salesforce ID, you cannot PATCH a new record, and you cannot POST to an existing record, and the /Id/ part of the path appears to be redundant and unnecessary. How is this pattern actually useful?

Hi,
When I tried to change the Quote Owner with current user I am getting the following error. Please help me.
 
Update failed. First exception on row 0 with id 0Q07F000000iCUWSA2; first error: FIELD_INTEGRITY_EXCEPTION, Can't change quote owner. Enable quotes without parent opportunities.: [OwnerId]
Error is in expression '{!processSelected}' in component <apex:commandButton> in page example_sprint: Class.CC_Contacts_Controller2.processSelected: line 130, column 1

An unexpected error has occurred. Your development organization has been notified.

 
Hello everyone,

I'm trying to deploy a package which contains Custom fields added on Account standard object with History tracking enabled. The deployment fails with the error 
The entity: Account does not have history tracking enabled
I enabled the history tracking on the account object definition and it is not working. 
<enableHistory>true</enableHistory>
can someone help me understand what is going on?

Thanks 
  • March 06, 2018
  • Like
  • 0