For Salesforce Data Entry Events there is no way of editing the entry source configuration currently.
The only way of "modifying" it is:
Create a new journey version
Delete the Entry Event
Configure a new Entry Event
Re-configure all activities using data of that event (decision splits for example)
A Salesforce Data Entry event is only editable as long as ...
info@ and mail@ are called "Role-based emails".
Because role-based and reserved email addresses often represent multiple recipients, they generate many spam complaints. To prevent unnecessary spam complaints, List Detective restricts these email addresses on imports and doesn’t send email to reserved email addresses.
You can use Custom List Detective to ...
Salesforce Marketing Cloud has a default setting that prevents the sending of emails to "generic addresses", such as admin@, info@ and so on.
This is likely the reason why these addresses have failed to enter the Journey.
Reference: List Detective
Yes it could, issues like this tend to happen if the tokens are not valid anymore. In situations like these it seems the Marketing Cloud Connector may still work for some functions between the Clouds, but fail without errors for others.
While I don't have a full list of features that tend to break, generally a good indication is also if you no longer see ...
Yes, and you don't necessarily have to link them together in Data Designer.
You can have one data extensions used as an entry source for your journey, and a second one that stores the "updated" data, and both of them set up as two different attribute groups.
As long as you have the same SubscriberKey in both of them, and it's related to the Contact Key in ...
These triggers are only invoked if changed from a non-matching value to a matching value. So if your field has the possible values A, B, C and D and your entry criteria is field = A OR field = B OR field = C the journey is only triggered if the original value is D and is changed to either A, B or C. If you change from A to B for example, your journey won't ...
You cannot set such a rule in an Automation that is sending email but here is a workaround -
Use a flag in your Data Extension which tells if its an updated record (eligible to receive email)
Then in your email, use AMPScript to fail the send for any subscriber which doesn't have the flag set
Here's what I think my be the source of your issue based on what you've shared:
In your production trigger that's working, you have the following condition that you test for:
if(objProduct2.Product_Identifier__c != null && ...
(Trigger.isUpdate || objProduct2.isActive) ... ||
objProduct2.isActive != objOldProduct2.isActive))
That line seems have ...
Kind of. It's a bit tricky.
Journey Builder does not detect existing record changes in the Data Extension, nor does it detect replacing a record in your Data Extension. This is known as the High Water Mark issue.
If an import or SQL activity is updating records in the event source data extension, they will not be assigned a new row in the data extension. ...
Well - the entire idea of Salesforce Data Entry Event is to inject a contact into a journey based on data changing in Sales Cloud. You set up the criteria on the contact object itself, or on any object relating to Contact. This can e.g. be Case which triggers injection of the contact into journey once Case status is set to closed.
You can define the ...
The way SF Data entry source works, there has to be a change within SFDC record. So the record has to be updated to not meeting criteria to meeting criteria. You can not say today + 4 since the record will not be updated to kick off the downstream process builder/apex workflow.
I would suggest using a boolean field, that you can set using a process within ...
So SF Entry events are for real time injection based on an upstream process. Since this process uses apex/flows/process builder within SFDC this is how the api call is made to inject a contact into a journey. If a record isn't created or updated it won't kick off the needed flows
You could simply create a DE off the data stream objects which would achieve ...
You can find the difference between Event data and contact data in the below link:
In a nutshell, in the entry source condition, event data and contact data will not make much a difference unless your data extension is updated frequently
In Decision split, you need to use ...
Contacts to Opportunities are not available in Journey Builder as a Journey Entry Source because of the One-to-Many relationship. A contact can have multiple opportunities. See relevant questions here: Journey Builder and Decision Splits with Contact Data.
Your best bet is to query the synchronized data extension to inject into your journey.
I don't see ...
You cannot target business accounts, so you can utilise the fact that every PersonAccount in Sales/Service Cloud has a Contact record associated with it. This Contact is linked via "Person Contact ID (Contact)", which needs to be used in the "Who do you want to inject?" step.
If you like to trigger the Journey for Business accounts you can only select ...
It's impossible to do with Entry Criteria based on record update. If you want to keep it on SFMC side, you can however pass Contact Type as Entry Data and make a decision split as first step in your journey. In that decision split check for Contact Type value, and for all undesirables exit person from a journey.
You aren't going to be able to change the primary key since that isn't (and shouldn't) be the unique identifier within Salesforce for a record.
If you want to prevent duplicate entries, and you are unable to use any other entry event type, you could run an automation to check the _sent data view for emailaddresses that have received a send from the journey. ...
One route is to use record types to control whether the submit for approval will be shown. If you have a lot of types of submissions, then this would be a bad way to go.
A route I have went is to create a specific actions on the record for the type of approval with required fields and then have a specific hidden field that triggers process builder. This ...
Once a contact has entered a journey, they're in the journey and they don't need to be in the Data Extension any longer. The entry into the data extension is the event that triggers the journey. As long as you have accounted for what will happen if duplicate contacts are added to the Data Extension there should be no problem with overwriting.
In your scenario it will not.
Contacts enter to Journey with static data where they originate, so with the attributes from your entry Data Extension.
If you later modify the data in the same Data Extension, then upon configuring Decision Split activity via Journey Data path, it will not actually check the Data Extension for the values, but instead use the ...
Create the Smart Capture form in CloudPages before creating this entry event:
To admit contacts into a journey, use Smart Capture forms created with Classic Content.
Give each Smart Capture form a name so it is selectable when defining your entry event.
Use a Smart Capture form with only one active journey at a time.
Drag Event onto the canvas.
Try to do !ISBLANK([Material_Request__c].Out__c) validation prior to any field validation(s) from this related record:
My guess is that you have a Query Activity in your Automation which is overwriting your Event Source DE.
Check the 'Update Type' in your Query Activity and confirm that it's set to 'Append' not 'Overwrite'. Overwriting will clear the high watermark.