Audit of the dataverse

[Anonymous]

Out of the box the audit logs SYSTEM user for all calls of the dataverse API and the owner of the flow if the changes done by flow. Is there any possibility to have audit to be connected to the portal users?

[justinburch · Accepted solution]

Hi @Anonymous,

No, all Portal actions are done via the default admin context (SYSTEM), and audit isn't setup to show the Contact table.

What you can do is add a "Modified By (Contact)" lookup to the tables in question, enable it for auditing, and then ensure your Portal update scenarios fill this field. As such, each time those fields are changed you'll be able to identify which Portal contact did it by that field changing. You can also leverage this on the Portal forms, and in Dataverse forms/views to identify directly on the table who last performed an action, if that's helpful as well.

Example of this can be found in the gifs of this post of mine - scroll down to End Result and see my forms after create/update: How to Differentiate Draft and Submit on a PowerApps Portal Form | Justin Burch

Examples:

Entity Form: Create Entity Form Metadata for Attribute = Modified By (Contact)

"On Save", Current Portal User, contactid

Web Form: Same, but in Web Form Step use Web Form Step Metadata

Power Automate / Flow: Fill via update package

[samnunn92]

Hi Justin

Thanks so much for this write up, it's been super helpful and we have now added this into our production portal. I had a quick question though if that's ok - it seems as though the ModifiedByContact field doesn't get updated on the Deactivate action. Viewing the Audit History in Dataverse shows the status change from Open -> Completed but the ModifiedByContact field remains the same. Is there any way to populate this field on the Deactivate event? Alternatively, is there a way to automatically save the form before it is submitted, perhaps intercepting the submit event somehow? I would really appreciate any advice with this as am not sure where to look next.

Kind Regards
Sam

[justinburch]

Hi @samnunn92,

Ahh.. the deactivate button calls an event called separately so it would (unfortunately) make sense that it's not updating the form. I'm not sure there's any easy way to hijack that event, but you could forego the OOTB button and create your own. For example, you could have a boolean that indicates "Is Complete" (with a better label, if using the field directly) and the user can "save" the record with that field to deactivate it; you would then use a real-time workflow to do the actual Status Reason change, so that it's all done as though the user deactivated it.

If you wanted to make it a little nicer, you could hide that boolean and replace it with your own "deactivate" button that you OnClick set the value to True and $("#UpdateButton").click() to trigger the form submission.

As far as your request to "intercept the submit," I last published a post on how to theoretically asynchronously save a form here: Asynchronously Saving a PowerApps Portal Entity Form | Justin Burch - you could consider adding the methods here as an event. If you do mean to save right before submit, then (it doesn't make much sense to me right now) you could replace the entityFormClientValidate method to call the async save. If instead you meant the Deactivate button, I find it easier to create your own button, call your own logic, then "click" the original button" to truly control the flow.

I hope this helps!