Imagine bringing your car to a repair shop for maintenance, but instead of designating a time when it’s supposed to be finished or leaving your number for a call, you have to walk over to the shop every day and check if your car is done. Worse yet, if they find an issue with your car, instead of calling you to discuss repairs and costs, they just ignore it — unless you ask.
Not a great feeling, right? I would struggle to trust this shop and probably never come back. So why is this the way many people build asynchronous processes in Dynamics 365? How many on-demand flows have you seen where just about no communication happens with the user after they started it? How many training sessions happen where the users are told “fill in this lookup field and then just wait a few seconds and refresh the page, then the products/contract lines/accounts will appear in this subgrid” – with no real information about what to do if they refresh and nothing happens?
The best result you may get in those cases is indifference, if your process is built very well and never fails. In any other case, this pattern leads to irritation and a loss of trust in the system with users feeling like they have to double-check everything they do, since they never know if there was a silent error.
Getting users on board with a new system is difficult enough — why make it harder by risking confusion?
This is going to be a series of posts about different ways to implement feedback to users, starting with data imports and one of my favorite tools – in-app notifications!
Causes of confusion
I really like the Excel Import features in Dynamics 365. Downloading worksheets, working on them in a familiar environment and then reuploading them is easy and in most cases works pretty well. Excel Online makes this even faster when there’s just this one column you need to change quickly and many first-time Dynamics users take quickly to these features. Press the button “Open in Excel Online”, change a few fields, save it and it’s done. Nice!
However, what happens when it fails? If you put in text in a numbers field or your Account Name can’t be found? Unless the person who uploaded clicked on “Track Progress” and then keeps refreshing (walking back to the repair shop every day), no one will be notified and hopefully it will not lead to more errors than just confusion and a muttered “I thought I already changed this?”.
When everything is going well, even people unfamiliar with Dynamics 365 see a system they can understand and handle. As soon as we leave the golden path, the confusion starts.
When a user triggers an asynchronous process, there are four questions which can be asked:
- Did I start the process correctly?
- What’s the current state?
- Did the process finish and was it successful?
- If there were errors, why did they happen (and possibly, how to solve them)?
Looking at Excel imports, only the first question is answered at the right time. Immediately after starting the import, users either get an error message or a success message and can be sure what’s going on. Every other question is only answered on the Import Source File form, which the user would have to open and refresh (pull-pattern) until the import is done.
The second question — what’s the current state? — is important for long-running processes and is the only one where a pull-pattern may be alright. However, constant updates may overwhelm the user. We’re not going to build a solution to answer this question in this post (keep an eye out for the next ones!), but if you’re dealing with a number of very large imports, you may want to build a small flow to notify your users that 25%, 50%, 75% of data has been imported.
Here, we’re focusing on the most important feedback: did the process finish successfully or did it fail? This information is far more valuable to users than progress updates in most situations.
When and why to use In-App Notifications
In-App Notifications are a great tool, but they can be misused, usually leading to too many notifications – and if users feel that way, there’s that handy “Dismiss all” button… So have some positive and negative indications if you should use in-app notifications for your use case.
- Low frequency – Use them if the process is not running frequently or the user is expecting feedback, otherwise users will feel spammed
- Time-sensitive – Don’t use them if handling anything that came up is time-sensitive, as the notification may be one of several or the user isn’t even working in Dynamics
- Targets one user – Use them if you have a clear recipient
- Must-see – Don’t use them if not reacting breaks your process. Notifications don’t have a “seen” status, and may not be seen at all!
- Target frequently working in Dynamics – Use them for recipients that are usually working in Dynamics every day
- High complexity – Don’t use them if you feel like you should send many lines of text or files. Link to that kind of data instead in the notification
Building the flow
We’re using the Added or Modified trigger on the table Imports, filtered on statuscode eq 4, meaning complete (usually I would also input statuscode in Select columns, but for some reason this leads to the trigger not firing at all).
Next, initialize the variable containing the default configuration for the notification and then check if either the number of successfully imported rows is equal to the total number of rows or if we have some errors. Depending on the outcome, we set the message text and the icon. To build the In-App Notification, I highly recommend using the In-App Notification Builder in XrmToolBox, especially for links and formatting. If you haven’t already, don’t forget to enable notifications for your apps!
Finally, we just create the notification row, using our configuration variable for values and setting the owner to the creator of the import.
Great, now our users will get a message when their import is finished and don’t have to guess if everything went well!
Next up, let’s tell them why any errors occurred.
Of course you could build some complicated action or flow here to try to construct an excel file, fill in all the error rows, get the error messages and send this to the user (No, I didn’t waste my time trying to do this in an elegant way, of course not). If your organization is using a lot of imports, this may even be the best use of resources.
However, let’s keep it simple for now. The question we want to answer is “If there were errors, why did they happen?”. Answering this question is a very different task from “Build the best, most streamlined recursive import process” and I want to emphasize that. The solution by Microsoft is not bad by itself (could be better of course), the core issue is that the user is not asked to review it at the right time!
So, for now, let us just add a link to the Import form and, most importantly, an explanation of what the user is supposed to do next! If you are building processes, always keep in mind how frequently a typical user is going to use them. If it’s infrequent, people will forget how the process worked last time and even a short explanation serves to jog their memory and prevent quite a bit of frustration.
Alright, now anyone importing data into Dynamics will actually know what happened with their import, if anything failed and what they need to do before trying again!
Closing thoughts
Imports are just one example where you can use In-App Notifications to give feedback to your users and improve the experience when using asynchronous processes. What about approval processes, on-demand interface actions or even any Power Automate Flow started with the “When a Row is selected” trigger?
Working on how users interact with the process can be just as valuable as refining the process itself — and is often easier to achieve. Try to go through your systems and processes and look for areas where users could feel a bit lost or unsure if his actions lead to the expected result – or any result at all. Addressing these gaps can greatly enhance trust in the system and make the overall user experience more intuitive.
Keep an eye out for more posts on this topic!