Is your organisation facing Dynamics 365 storage capacity limits after years of usage?
As your data accumulates with records and activities, it can eventually deplete the available storage capacity for each Microsoft tenant.
Purchasing more cloud storage could be a quick fix, but the recurring costs may not be sustainable in the long run. To address this challenge, how can you optimise capacity usage to minimise additional storage expenses?
Discover practical strategies in this post that can help you navigate this issue while saving costs.
How to check Dynamics 365 storage capacity & usage?
First, let’s look at how you can check your cloud storage consumption.
Log in to the Power Platform Admin Center to check how much storage is used for Databases, Files and Logs. Here, you’ll also find a breakdown of storage usage by source and environment.
By clicking the Details button, you can view the top database, file or log tables that are taking up space.
Now, what actions can you take to free up storage space?
1) Delete unwanted records and environments.
The first step is for administrators to delete legacy records in line with data retention policies and industry-specific mandates.
In the Power Platform Admin Center, you can also see suggestions of records from tables which you can potentially delete.
You may be legally obligated to retain some of your data for extended periods or indefinitely. But what about those sales leads that didn’t progress from more than five years ago?
You may be unaware of how dated some of these records are. Especially if your system has become bloated with records, processes and files that are no longer needed. This is an opportunity to run an audit. If you no longer require dormant records from more than a few years ago, this can be a first step towards freeing up capacity.
If you are unsure about deleting data deactivate first, then evaluate all the inactive items. This will give you a safety net to ensure you are not deleting any record users may need to access.
In many instances, a requirement for additional storage capacity will be caused by one or a combination of the following factors. It’s worth checking if it’s necessary to have these all stored in Dynamics.
- Emails and attachments – Large volumes of emails and attachments are one of the most frequent reasons capacity is exceeded.
- Audit logs – Tracking changes made to customer records. These are helpful when troubleshooting issues to see who made changes to a record, but they can quickly build up and should be reviewed and frequently purged.
- Suspended or errored workflow instances – While most process logs auto-delete if successful, this doesn’t happen for failed processes. Workflows can be suspended for various reasons, such as conditions that will never be met or other factors preventing the workflow from continuing. Suspended workflows still consume storage capacity, so create a procedure to identify and delete these.
- Environment – Examine the capacity of your sandbox or any other environment. Consider how many people use these and whether you need all that data. Environments consume data regardless of whether they have an associated database, so remove any that are no longer required.
Once you’ve determined what data can be deleted, the next question is how to delete these.
In Dynamics, there are two ways.
- Using Advanced Find
Using advanced find, look for emails and notes with attachments larger than a specific size and delete them if not required. When emails and attachments are deleted, you can free up space in Dynamics while still having access to them if they are saved in Outlook.
- Using a bulk deletion job
A bulk job can automatically delete larger and older files and processes. This process can be scheduled to run at a time of your convenience to create a bulk deletion system job instance, which can also be deleted.
Refer to these documents for a step-by-step guide on how to delete records:
2) Move data out of Dataverse.
If you have a high volume of emails with large attachments which cannot be deleted, looking for a solution to move data out of Dataverse into other systems becomes financially viable.
That’s because the ongoing cost of an SQL database or Azure Blob Storage is significantly lower than the additional Dataverse storage capacities.
Previously, Microsoft had an add-on solution called Attachment Extractor to move attachments from Dynamics to Azure Blog Storage, which is now deprecated. Data Export Service was another add-on to replicate data from Dataverse to an Azure SQL database, but is also deprecated.
However, we have built a custom solution to transfer emails and attachments to Azure SQL and Blob Storage. This uses Azure data factory and present these in Dynamics using Virtual Tables. As a result, you can continue working with these files in Dynamics as if they are stored in Dataverse, but without consuming D365 storage.
Once data is moved to the Azure SQL database, it stores a record ID back in Dynamics. This guarantees it has been archived, avoiding the possibility of deleting records if the archiving fails.
Complex criteria can be built to determine which files you want to archive and when. For instance, we can create a rule to archive emails related to case records older than 18 months. Another criteria can be to archive any emails unrelated to a case after three years.
In addition to an existing Dynamics 365 environment, this solution requires the following:
- An Azure subscription to host the Azure SQL database
- Azure data factory for transferring data from D365 emails to Azure SQL and email attachments to Azure Storage.
- App Service Plan to host the App Service (OData) that will read data from the Azure SQL DB table and push this into Dataverse using a Virtual Table
This extraction process reduces storage costs by benefiting from the lower-priced Azure SQL storage model when archived data is moved from Dataverse. The costs and potential savings will depend on your data volumes, the Azure database, and the selected OData App Service hosting plans.
This solution can be accessed by subscribing to our Dynamics 365 managed service.
3) Maintain and review your data retention policy.
Finally, take proactive steps to ensure you have good data management practices.
If you don’t already have a Data Retention Policy, this is recommended to comply with data protection guidelines.
We have built a Data Retention Policy solution to help customers proactively track why records are stored in Dynamics.
This also highlights when some should potentially be removed. For example, a rule can be configured not to keep any contact record unless there has been a support case, order or tracked activity within 3 years. If there’s no good reason to keep a record stored in the database, use this solution to identify and deactivate them.
How much cloud storage do you get with Dynamics 365?
Dynamics 365 Online data is stored in Microsoft Dataverse. The following default capacities are available:
- Dataverse for Apps Database: 10 GB (Transactional database storage for entity definitions and record data)
- Dataverse for Apps File: 20 GB (For storing attachments on emails and notes in Dynamics 365 apps, including PDF and image files)
- Dataverse for Apps Log: 2 GB (Audit logs to track records and attribute data changes)
Additional storage entitlements are accrued for each D365 Enterprise user licence as follows*:
- Dataverse for Apps Database Capacity: @ 250 MB per user
- Dataverse for Apps File Capacity: @ 2 GB per user
- Dataverse for Apps Log Capacity: n/a
* Include D365 Sales Enterprise, Customer Service Enterprise, and Field Service licences.
Storage capacities and current usage are managed in the Power Platform Admin Centre.
Notifications are triggered when a tenant has less than 15% of space available across its three storage capacities. If capacity is exceeded, a user cannot copy, restore, create or recover an environment.
We assist organisations with their storage optimisation as part of our managed service.
To discuss your Dynamics 365 cloud storage and identify where efficiencies can be made, enquire now to speak to one of our consultants.