D365 Customer Insights for Our Own Sales Team (Customer Zero) (3) Fixing the D365 Sales Customization
This continues from Part โก. As part of Customer Zero, we planned to extract customers with no contact activity in the past 90+ days and send activity recommendations to sales reps. To support that segmentation, we had added a "Last Activity Date" field back in Part โ . However, the Power Automate flow wasn't running, and we discovered the following.
The Problem: activitypointer Cannot Be Used as a Dataverse Trigger
Due to a Dataverse platform constraint, it is not possible to register a trigger (callback registration) against the activitypointer entity. This is because activitypointer is not a real table with its own data - it is an abstract aggregation view that surfaces records across multiple concrete activity tables: task, phonecall, email, appointment, and others.
Power Automate's Dataverse trigger ("When a row is added, modified or deleted") does not support detecting changes on abstract entities like this. In other words, specifying "Table: Activity (activitypointers)" as the trigger target was a fundamentally unworkable design from the start.
The Fix
Instead of a single activitypointer trigger, you need to create a separate trigger for each concrete activity table.
Steps:
- Open the C-6 flow in edit mode.
- Change the target table of the current "When a row is added, modified or deleted" trigger from
activitypointerto a concrete table (e.g.,task). - Apply the same logic (update the related Account when
statecode = 1) and duplicate the flow for each required activity type:- Task (
task) - Phone Call (
phonecall) - Email (
email) - Appointment (
appointment)
- Task (
- For the "Get a row by ID" step (fetching the Opportunity), select
regarding(value) as the row ID. - The third flow also needs to be updated - set the row ID to
Potential Customer.
After testing, the update was correctly reflected, confirming success.
Duplicating the Flow (Common Steps for Phone Call, Email, and Appointment)
Since C-6 (Task version) is working correctly, use it as the base and duplicate:
- In the flow list, open the verified "C-6 Write Back Last Activity Date" (Task version).
- Click "..." (More options) in the top right โ "Save As" to duplicate.
- Rename each copy following the naming convention:
- C-6 Write Back Last Activity Date (Phone Call)
- C-6 Write Back Last Activity Date (Email)
- C-6 Write Back Last Activity Date (Appointment)
- In each copy, change only the trigger table name:
- Phone Call (
phonecall) - Email (
email) - Appointment (
appointment)
- Phone Call (
- The "Get a row by ID" (Opportunity fetch) and "Update a row" (Account write-back) logic can be reused as-is - no changes needed.
- Save and run a test.
One Important Caveat
The logic in these flows assumes that the activity's Regarding field points to an Opportunity. However, phone calls, emails, and appointments are more likely than tasks to be linked directly to an Account or Contact rather than an Opportunity. If the Regarding target is an Account rather than an Opportunity, the "Get a row by ID" step will attempt to look up the Opportunity table and return an error (the same Entity Not Found pattern as before). Make sure the table name and logical name are configured correctly for each flow.
Comments
No comments yet. Start the discussion.