D365 & Beyond by Sid

Blog

  • Exit RTM Journeys using Exit Criteria -Part 1 using Custom Triggers

    Today we will see how we can exit a RTM journey in between using Custom Triggers.

    Generally in sales journey we often come across scenarios where after a certain product is bought by the customer then we need to exit that customer from that particular Journey so that the customer won’t receive any similar promotional emails as the customer has already taken up your product, so now there’s no need to send him/her the same follow-up emails.

    I am going to use a simple journey to showcase this scenario.

    As per above “Customer Tracking Journey #1” – We are targeting specific customers, in our case segment with predefined 7 members. So once they enter the journey next step I have created is a Create Task step to make a task for the customer owner to follow up with them.

    After that I have added a wait of 15 minutes so that after 15 minutes it will move to the next step of creating second follow up task for the Contact owner.

    Now we will take a scenario where suppose while first follow-up the customer buys the product so now we don’t need to have the second follow-up task i.e. we need the customer to exit from the journey.

    Here we will make use of below setting –

    In the Journey itself from right hand corner you will see the option to specify the Exit criteria. By Default it uses Complete All Steps. But as we need to use some conditional exit so I am going to select Alternate Exit Option 1 i.e. Exit when a trigger occurs.

    In this case I am using below custom trigger –

    I am using OOB trigger – i.e. When “Exit Journey” record (related to the contact) is created. So when this record will be created the respective contact should exit the journey.

    Once my journey was live it showed below results –

    So as you can see here only 4 contacts went ahead after the first wait of 15 minutes and 3 contacts exited the Journey. The 3 contacts exited the journey as I had created 3 Exit Journey records for those contacts as you can see below-

    In this example I have used Contact, but similar can be achieved for Lead too. With this approach we can have the customer exit the particular journey based on the Custom Trigger.

    Note- Only one thing I am unable to find is the details of contacts exited the particular journey. But as I am using Custom entity to track it, I am able to figure out that details for now.

  • Use Dataverse Table Create/Update operations in Custom Trigger to add wait in the Real Time Journeys!

    In the last blog we saw how we can use Custom Triggers to wait in the RTM Journeys and send the data to Azure Service Bus and then executing the “WaitTrigger” using OrganizationService Request move ahead in the Yes branch. Today we will look into another approach where instead of executing the WaitTrigger through code how we can use Dataverse table to serve the purpose.

    So first create the custom trigger following below steps –

    1. Go to Dynamics 365 Marketing App — Real Time Marketing Area — Triggers — Click on New Trigger. You will get 2 options-

    2. Give name to the trigger suppose “IsAssigned” and select the first option “When a record related to a customer(Contact or lead)” is created or updated, and click Create.

    3. Here we need to select the table having lookup of Contact or Lead. In our case we will select Assignment Table as we have lookup of Contact on it. The next thing to select is “When is the trigger activated?” As you can see we can select Create record, existing update or even any of the both. For our scenario we will select “An existing record was updated”

    4. After that we will select the attribute on update of which we want the trigger to fire in the options” Which attribute updates should activate the trigger?” which displays the attributes of the selected table. Then click on Ready to Use.

    5. After that we will move to the RTM Journey and add the option Respond to Action and select the Wait for – A trigger is activated and Choose the above trigger “IsAssigned”. After that add the condition which it should satisfy like Is Assigned = Yes in our case.

    6. Now when the journey is live it will wait for the respective action to get completed i.e. within the time limit specified in the wait condition, in our case it will wait till the IsAssigned trigger is activated. And once the related “Assignment” record is updated the respective customer will flow in the Yes branch as below –

    Above example we have given using Contact level audience, same can be achieved even for the Lead level records.

    Hence to conclude, this was an alternate approach where using the contact/lead related table itself in the Custom Trigger we can have the wait condition achieved in the RTM Journeys !!

    Happy D365 Marketing !!

  • Tip – Working with Custom Triggers, Azure Service Bus in D365 Marketing!!

    Custom Triggers in Real Time Marketing helps us to achieve different Integrations with multiple system and the contacts in D365 Marketing. There by helping to facilitate the Journeys through various channels and systems. Today I will explain here one of the use case which I recently came across.

    I had a requirement where I had to assign the available Offers(Table) to the contacts entering the Journey. And on successful assignation of Offers we had to continue the journey to send the related offers through Email.

    So here I decided to have one custom trigger “Grant Offer” to be called in Journey as below –

    And then when the custom trigger gets called pass the data to Azure Service Bus through Endpoint Integration with D365 Marketing.

    Reference for Azure Integration and registering Service End using Plugin Registration Tool- https://learn.microsoft.com/en-us/power-apps/developer/data-platform/walkthrough-configure-azure-sas-integration?view=op-9-1

    So basically as explained in the blog we had registered Plugin Step on the Service Endpoint with the message set to “msdynmkt_grantoffer_XXXXX” which is nothing but the Custom Trigger which we had created in RTM(Real Time Marketing).

    It was ok till this point, the real challenge was with the further requirement where we had to wait till the Offer records are updated with the contact lookup entering the journey. As we were sending the value of this offer record in the Email so we had added a wait condition for 5 minutes as below –

    This was ok till the count of Contacts entering the journey was less like 50-100. Actual problem started when the record count in journey increased. I mean lot of messages were posted to the queue and the processing time was more than 5 mins. So what happened is the contacts started receiving Empty Offer values in the email as the wait time of 5 minutes was completed for that particular contact and it was still not processed by the ASB (Azure Service Bus) listening application.

    Increasing the Wait Time to 1 hour or such would have caused all the contacts in the journey to wait till the specified time. So this was not efficient and expected as every contact was forced to wait for 1 hour till it completes the processing.

    After checking the available options, I found that we can use a custom trigger to achieve this. There is an option “Respond to an action” which can give us way to use another trigger as shown below –

    After adding the above step we get below screen to configure the setting –

    After selecting the “A trigger is activated” option in Wait for condition and selecting the new trigger “Wait till Offer Granted”, I got the option to select the attribute “IsAssigned” which I had created as parameter for the “Wait till Offer Granted” trigger. So I configured the condition as shown below

    As you can see here there is Time Limit selected as 5 hours so it means at the max it will wait till 5 hours and then it will proceed to “No” branch.

    Further, the most important change I had to add was the logic to call this new trigger “Wait till Offer Granted” from my ASB listener application, just after the Offer record was updated with contact lookup, just how we usually execute any OrganizationRequest in CRM C# application.

    Also, one more highlighting part here is the bindingid attribute which I had used while calling the wait trigger by passing the value of parent journey id i.e. of “Offer Send Journey”. This makes sure that the “Wait Till Offer Granted” trigger only activates for the related parent journey and not any other journey where the same wait trigger is used.

    And then guess what moment the trigger was called for particular contact in the journey it worked like charm! The contacts just started flowing in the Yes branch and I was able to manage my logic using another Custom Trigger. The Wait limit of 5 hours was just used to make sure my ASB listener will complete the process for the contacts flowing in the journey.

    Hope this approach helps you next time you try to incorporate WAITS in your Journeys in RTM.

    Cheers!!

  • Tip – Getting Field Length Error in Power Automate even after updating the length in Dynamics 365

    Recently we had a scenario where we were creating a new record through Power Automate step of say Entity A. We started getting error for the field length being less than the input character. So being production instance we moved the patch of the managed solution from dev to Production increasing the length of the field.

    Inspite of moving the updated length of the field we were still getting the same old length error in the Create step in Power Automate.

    We found that we had to just bring the Power Automate again from the dev instance to the Production instance.

    One more possible way can be just to edit the flow and reactivate it in the environment where it is not working.(As my issue was fixed by moving the Power Automate I was not able to try this part, but you can try this if moving power automate from dev to production is not feasible for you.)

    So next time if anyone faces such problem with the field length update in D365 not working in Power Automate even after moving the solution then you can keep the above approached in mind.

    Hope this helps and saves your time !

  • Tip – RequireNewInstance property to handle TimeOut issues while using CrmServiceClient (XrmTooling)

    Recently we had created a windows service which was running continuously on our server. The very next day we started getting Timeout exceptions for the OrganizationServiceProxy created using CrmServiceClient using XrmTooling. This was due to session getting expired after 24 hrs.

    We decided to investigate on this and came across a way to fix this. We found this attribute “RequireNewInstance” which can be passed in the connection string which did our job.

    We included the connection part in our while loop and in that we set RequireNewInstance = false while creating connection using CrmServiceClient, so that it will create new instance only when required and use the existing cached connection when the service is connected and not expired.

    Using this we were able to resolve our timeout issue as when the service gets expired it creates a fresh token and caches it, until it expires. there by not impacting the application output.

    while(true) 
{
//Had our logic to read the data continously from Azure Bus
var connectObject = new CrmServiceClient($@"AuthType=ClientSecret;url={organizationUrl};ClientId={clientId};ClientSecret={appKey};RequireNewInstance=false");
}