2 added 507 characters in body
source | link

Like I thought, it didn't have anything to do with the code as such but the issue was as follows:

Salesforce itself also has it's logic to determine if the "IsExternallyVisible" flag should be true or false. You can find an explanation of their logic here:

http://releasenotes.docs.salesforce.com/en-us/summer15/release-notes/rn_service_emails_case_feed.htm

What is important to know is that the code of Salesforce for the IsExternallyVisible flag executes between the "before insert" and "after insert" event.

We didn't know that at first and logically, our logic to set the IsExternallyVisible field was being launched in the "before insert" handler.

So, in the end, causing the Salesforce logic around the IsExternallyVisible to be the boss instead our own custom logic...

So, how we will fix it is either:

  • executing the same logic but in the after insert. (meaning we will have to re-query the records cause those from the trigger context would be read only)
  • or, executing the logic as a future method

In my eyes, this is very strange behaviour of Salesforce and in any case not handy. They should at least put this a bit more clear in the documentation. Will definitely log a case for this.

UPDATE: I assume the logic will also have to be executed in the "after update" for the case where someone would have first saved an email message as a draft...

UPDATE 2: it was not possible to execute the code to set the IsExternallyVisible flag in the after insert and I had to do it with a future method. When trying to update the email message in the after insert, I got something like method not allowed, or some permission error. I remember getting this when the email message you were trying to update also contained other fields apart from the "IsExternallyVisible" flag but this wasn't the case now. Doing exactly the same in a future call did the trick.

Like I thought, it didn't have anything to do with the code as such but the issue was as follows:

Salesforce itself also has it's logic to determine if the "IsExternallyVisible" flag should be true or false. You can find an explanation of their logic here:

http://releasenotes.docs.salesforce.com/en-us/summer15/release-notes/rn_service_emails_case_feed.htm

What is important to know is that the code of Salesforce for the IsExternallyVisible flag executes between the "before insert" and "after insert" event.

We didn't know that at first and logically, our logic to set the IsExternallyVisible field was being launched in the "before insert" handler.

So, in the end, causing the Salesforce logic around the IsExternallyVisible to be the boss instead our own custom logic...

So, how we will fix it is either:

  • executing the same logic but in the after insert. (meaning we will have to re-query the records cause those from the trigger context would be read only)
  • or, executing the logic as a future method

In my eyes, this is very strange behaviour of Salesforce and in any case not handy. They should at least put this a bit more clear in the documentation. Will definitely log a case for this.

UPDATE: I assume the logic will also have to be executed in the "after update" for the case where someone would have first saved an email message as a draft...

Like I thought, it didn't have anything to do with the code as such but the issue was as follows:

Salesforce itself also has it's logic to determine if the "IsExternallyVisible" flag should be true or false. You can find an explanation of their logic here:

http://releasenotes.docs.salesforce.com/en-us/summer15/release-notes/rn_service_emails_case_feed.htm

What is important to know is that the code of Salesforce for the IsExternallyVisible flag executes between the "before insert" and "after insert" event.

We didn't know that at first and logically, our logic to set the IsExternallyVisible field was being launched in the "before insert" handler.

So, in the end, causing the Salesforce logic around the IsExternallyVisible to be the boss instead our own custom logic...

So, how we will fix it is either:

  • executing the same logic but in the after insert. (meaning we will have to re-query the records cause those from the trigger context would be read only)
  • or, executing the logic as a future method

In my eyes, this is very strange behaviour of Salesforce and in any case not handy. They should at least put this a bit more clear in the documentation. Will definitely log a case for this.

UPDATE: I assume the logic will also have to be executed in the "after update" for the case where someone would have first saved an email message as a draft...

UPDATE 2: it was not possible to execute the code to set the IsExternallyVisible flag in the after insert and I had to do it with a future method. When trying to update the email message in the after insert, I got something like method not allowed, or some permission error. I remember getting this when the email message you were trying to update also contained other fields apart from the "IsExternallyVisible" flag but this wasn't the case now. Doing exactly the same in a future call did the trick.

1
source | link

Like I thought, it didn't have anything to do with the code as such but the issue was as follows:

Salesforce itself also has it's logic to determine if the "IsExternallyVisible" flag should be true or false. You can find an explanation of their logic here:

http://releasenotes.docs.salesforce.com/en-us/summer15/release-notes/rn_service_emails_case_feed.htm

What is important to know is that the code of Salesforce for the IsExternallyVisible flag executes between the "before insert" and "after insert" event.

We didn't know that at first and logically, our logic to set the IsExternallyVisible field was being launched in the "before insert" handler.

So, in the end, causing the Salesforce logic around the IsExternallyVisible to be the boss instead our own custom logic...

So, how we will fix it is either:

  • executing the same logic but in the after insert. (meaning we will have to re-query the records cause those from the trigger context would be read only)
  • or, executing the logic as a future method

In my eyes, this is very strange behaviour of Salesforce and in any case not handy. They should at least put this a bit more clear in the documentation. Will definitely log a case for this.

UPDATE: I assume the logic will also have to be executed in the "after update" for the case where someone would have first saved an email message as a draft...