Microsoft introduced a set of new audit features helping Dataverse administrators to stay compliant with internal and external auditing requirements and to manage log capacity at the same time.
Audit data is now also stored in a separate physical log storage so an organization’s audit log can grow to many terabytes in size without limiting available physical database storage. This change in physical storage is independent from the continued need for having sufficient storage entitlements for logs and database records.
What is the auditing feature?
The auditing feature logs changes that are made to customer records and user access so you can review the activity later. The auditing feature is designed to meet the auditing, compliance, security, and governance policies of many regulated enterprises.
Audit retention policy
Administrators can select an audit retention period from a dropdown menu or specify a custom retention period. Audit records are automatically deleted after the retention period is over, relieving administrators from the burden of deleting audit data manually. It is also possible to keep the audit log indefinitely by not specifying a retention period.
Audit settings with the option to specify a retention period.
With new flexible audit deletion options, we are removing a major pain point our customers were facing frequently: how do I delete a subset of the audit logs while keeping the rest?
We are introducing a set of new audit deletion options so administrators can delete the logs of one or more audited tables, delete the user access logs, or delete logs up to a specific date in order to free up storage space. The new delete options are replacing the audit log management view and quarterly log partitions.
Imagine you have an application that requires authenticating a data source with a particular client id or a secret key. You would not want to expose those secret values to other authors or users of your application. In such a case you would want to store these sensitive values, which are important to the functioning of your application, in Azure Key Vault. The example used in this blog to support secrets, we are storing the clientid and authentication key as secrets in Azure Key vault and referencing those values when deploying them from one environment to the next. This blog highlights the assumption that data sources used in development environments are different than the similar data sources used for QA, which requires updated values for your clientid and authentication key to such data sources. For the basic concepts of Azure Key vault please refer to the documentation.
Figure 1: Example of a secure application using Azure Key Vault for storing application secrets
Grant the SPN for the CI/Cd Pipeline access to the target environment Key Vault
In this example, we have a ServiceNow connector, which is used in an application within Power Platform, this is similar to the setup mentioned in the blog. Two different ServiceNow instances are used, one for development and another for testing purposes.
Figure 2: Flow of the ALM pipeline sequence
The service principal account that you are using needs to have read access to the target environment’s Azure Key Vault. In this example I have a production key vault that I use to secrets for my QA and Production environment (it is recommended that you have separate Key Vaults for Dev, Test, and Production not like my setup which is a demo environment)
Figure 3: Provide SPN account being used to run the Pipeline reader access
SPN account needs access to the target environment
To make sure that the SPN can deploy to the target environment, make sure that the SPN has access to and the right role setup in the target environment, which is typically the System Administrator role.
Figure 4: SPN access to the target environment to deploy the solution
setting up the Azure DevOps service connection
To set up the service connections in Azure please go to the project settings and select Service Connections.
Then proceed to specify the connection details for the environment
Figure 5: Specifying details for the service connection
You can do this for both your Development and QA environments, or any other Power Platform environment you might be using in your pipeline. Ideally, you should have different SPN accounts that deploy to QA and to Prod and not use the same SPN account if possible.
Setting up your solution
You can set up the environment variables with references to Azure Key Vault Secrets using the following blog from Sameer Chabungbam
Using Azure DevOps to store the solution to source
So, we will create a pipeline that will extract the solution from the development environment and commit the artifacts to source control. In this case my pipeline exports the solution from the development environment and checks-in both the unpacked solution and the solution zip into the repository. For more details on how to setup Azure DevOps with Power Platform build tools please to this link
Figure 6: Getting solution from the development environment and committing to source
Inside the Git repository in your Azure DevOps environment, you will see the following:
Both the SvcNow.zip (solution zip file) and the unpacked solution file are now in the repository. For secrets, we recommend that you do not create default values with the location of your secrets and only store them as current value.
Create the deployment settings file and provide target values
To create the deployment settings file, you can proceed to open the repository in VS code with the Power Platform extension installed and run the create-settings subcommand under the Power Platform CLI command. Running the create settings file creates a settings json file that can be populated with the values for the target environment.
Figure 7: Creating the deployment settings file
Open the new settings json file and supply the values for the target environment. Keep in mind the string value on how the path to the Azure Key Vault is provided.
Figure 8: update setting file with the target values
Check in the changes into the repository and let us proceed to deploy the solution into the target environment.
Running the deployment
Once the changes are committed into the code repository, as shown in Figure 9, we can proceed to start the deployment pipeline.
Figure 9: checked-in deployment settings file
Now in the pipeline menu let us create the Power Platform Deployment Pipeline to deploy to QA. The Key tasks here are the pack, Solution Checker, and the import command (but don’t forget the tool installer as your first step).
Figure 10: Solution import settings in the deployment pipeline
Make sure that you have selected the “Use deployment settings file”, this is a key operation to make this pipeline work with Azure Key Vault for the target environment.
Figure 11: Example of a deployment run into QA
Once the deployment is done you can now check the solution in the target environment with the appropriate values.
Figure 12: Changed Key Vault values for the Target QA environment
Microsoft announced the General Availability (GA) of Power Apps portals support for Query data using portals Web API that was introduced in November 2021 release as a preview feature.
Independent Publisher connectors are connectors developed, tested, published, and supported by connector developers that are independent from the backend service or API. The Microsoft Certification team performs validations and checks to ensure that the connector is safe to use.
Finding and then acting on information in model-driven apps can take two forms: Searching for specific records (which we modernized recently through Dataverse search) and exploring a table for record sets that meet a specific criterion: Advanced find. Microsoft announced the availability of modern advanced find that not only replaces the legacy experience but also adds new enhancements to view personalization to help you be more productive with model-driven apps.
Explore data through advanced filters on any table in the app
Using the global search bar in the header, you can now choose any table in the app to perform a structured search. Choosing a table navigates you to the familiar grid page, with filter options immediately available to work with.
View selector enhancements to help you create and find views easily
After you have edited the filters and included the right columns in the view, you can find the options to create a personal view within the view selector, along with other options to manage the view list.
As you create more views, you can browse them easily in the view selector, with personal views annotated with an icon. You can also search for a view by name so you can be more productive in navigating between different pivots of data.
Personalization options to see the most relevant views
If you have created a lot of personal views over time, finding the right view quickly can be difficult. With two new powerful personalization options available with modern advanced find, you can make the view list your own, so the most relevant views are easily accessible.
Hiding a view in the view list
You can hide one or more views in the view list to ensure only the most relevant views show up in the view selector. Views are hidden only for you across all devices for that table in the environment.
Changing the order of views
You can make the list of views appear in one of three preset orders. If you have tables in which you prefer to use system views over personal views, you can change the order of views in the view selector across all devices for that table in the environment.
View management options to collaborate with views
You can also collaborate with your team members by sharing personal views just like you would share any other record.
