Dynamics Customer Engagement
Evolution of Common Data Service for Apps Storage
Topic: Database Storage for Dynamics Customer Engagement is changing, and in this blog, we will help you understand how this will impact your Dynamics Landscape.
- Database Storage Breakdown
- Customer Scenarios
Database Storage Breakdown:
Let’s first understand the DB Storage breakdown, which will help us to get more clarity on the Pricing Model.
At present, DB Storage for all the Dynamics customer is being calculated as per the total Data residing in their respective Instances. There was no segregation parameter or breakdown defined by Microsoft for the overall data stored in the DB.
As more and more millions of transaction are occurring, it makes sense for Microsoft to come up with some sort of strategy to make better utilization of the DB real estate. This will definitely help every customer understand their usage and will eventually benefit customers to optimize their database storage.
Today: No Logical Segregation of DB Storage
Tomorrow: Three areas to calculate your Storage
Best way to understand is with an example!
- Database Capacity
- Contact, Account or Any Entity which stores records.
- Customization and Configurations (Adding\Updating New Entity, Workflow, Plugins, Web Resources Etc.)
- File Capacity
- Email Attachment, Document Attachments
- Audio, Video Files
**Any Document stored inside Dynamics Notes Area. Excluding Document Management Area (SharePoint).
- Log Capacity
- Audit Logs or Any Change Tracking Logs
** More to come as we need to get clarity whether system jobs, Plugin Exception Logs will be captured in Log even though they act like a record.
Below is the simple overall understanding of pricing model.
- Each FULL Enterprise USL will give you an additional Database Capacity and File Capacity. No need to buy increment of 20 Full USL for additional Database Storage.
- No Charges for Instances. Every 1 GB of available Database Capacity will resonate towards creating a new instance.
**Note: Database Capacity is different from File Capacity.
If you have 20 GB DB Capacity and 40 GB of File Capacity, then the math is we can create 20 Instances max.
However, it will be hypothetical to create 20 Instances when only 20 GB DB Capacity is available since we will run out of DB Capacity to store Entity Records.
Recommend to have at least 2 GB for each Instance. So in our case, we should limit to creating 10 Instances.
- Customer Save $70/Month + $0 for Instances
- 110 GB File Storage at No Additional Cost.
- Overall good savings
- Database Capacity Cost is increased drastically. However, the overall there is still gain with No Payment for Instances.
- 110 GB File Storage at no Additional Cost
- Overall Balanced Gain.
- Customers who have Team Member Licenses will have a major impact. Since there is no Data Capacity Provided. Only FULL USL will get additional Data Capacity.
- In Practical (General Implementations) scenarios customer tends to have at least 4-5 No Prod Instances (QA, UAR, PER, DEV).
- Overall there will be a minor cost increase.
There should be an overall gain to the customer and more clarity on their Data Usage. We will continue with this Topic in upcoming Blog Part 2 with some real time Capacity Logging Dashboards, Timeliness, and Important FAQ