I strongly suggest you use the time-based workflow and email/notification workflow to do this usecase.
At a high level you will do the following. I will use C4C Ticket as an example which could easily be true for any C4C object like Oppty, Lead, Activity, Quote, Order, etc...
1. Configure workflow trigger to a time based event (24 hours after the Ticket "Changed On" date
2. Configure workflow condition where if the Ticket Processor is "blank".
3. Configure workflow action to send email, create BTM notification, and/or field update of a header field of the Ticket
If the workflow action is more complex such as updating a node field, creating node entries, creating follow-ups etc... or the if the workflow condition needs to evaluate a BO node field, BO node event like when a record is saved, then you will need to combine the workflow engine with some SDK ABSL/reuse functions to achieve the advanced logic you want to evaluate or orchestrate.
For example,
1. If you want the workflow engine to trigger an email/notification when a particular Involved Party member, Ticket line item, and/or attachment is added/removed/edited from the Ticket, you will need to create a before save node exit, where it would evaluate a condition true or false. If it is true, then update a Ticket header indicator extension field. Then create a workflow rule condition to evaluate if the Ticket header indicator field is true or false, then the workflow engine will execute the workflow action with one extra step to do a field update action to clear out the Ticket header indicator so that if another change is on the node, then workflow engine can be triggered again.
2. If you want the workflow engine to trigger business logic such as creating a note entry in the Ticket, insert a default product in Ticket line item, and/or create a follow-up Opportunity, then do the following
a. Create a custom header action on the Ticket. In the custom header action add the logic you want to create/edit in the Ticket node. You may even want to create a Reuse function to make the logic more generic and accept parameters and be consumed in other places besides this custom action
b. Create a custom indicator on the Ticket header
c. Create a beforesave exit on the Ticket header where if the indicator is set true call the custom action. Once the custom action is executed, then set the indicator back to false
d. Setup a workflow condition where it would evaluate if the Ticket header indicator is true or false, if it is true, then call the workflow action which could be a simple email/notification/field update or again combine it with example #1 to call a custom follow-up action
With these two design patterns you can cover just about any business logic automation scenario with a few lines of code and point and click configuration with the workflow engine.
The SDK MDR framework is great for batch processes, but often you can do these event based processes combined with the timebased conditions to get to a similar use case. If you decide to create a SDK MDR, be careful as I have seen some poor implementations that do not account for object locking and a retry logic to guarantee that the batch process will always do the "action" no matter what. Often this is overlooked and you will find that the batch process will fail, with no notifications to the admin, and no way to retry the batch process for the failed objects, etc... so you have a great demo feature, but in a realistic production scenario will never be scalable from an operations point of view by the customer.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.