The Finance and Operations servicing provides organizations with ERP functionality that supports their unique requirements and helps them adjust to constantly changing business environments, without requiring that they manage infrastructure.
But before delving into Service, Support, and Maintenance, we’d like to walk through a couple of service activity responsibilities.
The thing is, even though Microsoft provides support for the infrastructure, the platform, and monitors the production keeping it in a healthy state – that may not be enough to ensure your system is secure. There are some responsibilities that fall on either you or your implementation partner’s shoulders.
Configurations, customizations and the management of the system itself are must be tested prior to new deployment or service update ensuring regression testing. This forms the joint responsibility of the MS team and your organization.
Joint Responsibility
The Microsoft team is definitely committed to building a scalable platform with solid infrastructure, databases, apps, and so on.
Nevertheless, during the implementation phase organizations add building blocks for specific features and/or services, a customizing system for their specific business processes and needs. Meaning, there are almost no “standard” apps out there, as the code is being changed to satisfy the organization’s needs – data constellation itself defers from business to business.
The integration part is different from customer to customer, as well as the reporting part, with whole analytical intelligence.
This drives the topic to a single conclusion – the MS team cannot maintain D365 Finance and Operations Apps’ health on its own. Meaning, it creates a joint force to service, support, and maintain the whole system.
So how would you do that?
Lifecycle Services (LCS)
The best toolset to use for the servicing is actually should be familiar to you – lifecycle services, or the collaboration portal. The one, also known as LCS, has already been utilized during your implementation and monitoring parts.
Since the LCS has been mentioned and because the Finance and Operations Apps, like, if we think about project operations, if you think about some specific addons, they are running on top of both the Finance and operations platform as well as database.
That means, that you as a customer or supporting actor need to make yourself familiar with the power platform admin center (PPAC).
Self-Service Action LCS
Moving to service scenarios, most of them would be self-service actions. Nevertheless, some of them can be addressed by support tickets. Here is the majority of servicing actions:
- Environment deployment, which is usually processed within two days;
- Package application to the production environment;
- self-service actions related to database movement, including refresh and restore actions, as well as pushing sandboxes to production prior to moving live;
- Maintenance mode to ensure safety by letting admin users submit changes without endangering the system;
- Pause upcoming automatic deployment of a service update;
- Restarting services on non-production environments;
- Azure SQL actions.
There is still also a few “Service Request LCS” request types, which are:
- Database movement operations, if not available as a self-service action;
- Other requests like Production Tenant Move and Power BI Embedded Activation.
Support Ticket LCS
In case there is no self-service action to satisfy your needs, then you should submit a support ticket, which is the way to reach the Microsoft team.
An example scenario would be regression testing for a new service update. Should you want to aware the MS team about the regression – that’s the case submit the ticket.
Let’s have a look at another one. Before you go live, the subscription estimator is usually filled in to estimate the load on future D365 Finance and Operations Apps. However, if you know that there is a business expansion, or you are going to have a big country rollout for instance, and you know the load will be increased drastically – submit the ticket, so the MS team is aware of it.
Data Backup and Retention
Finally, a few words about database backup and retention. The database is protected by automatic backups and it is important for production to know about a retention period of 28 days. Also, for these sandbox environments, the retention period will be only 7 days.
Should you need backups for a longer time, you would have to take care of the retention period by yourself through data refreshing in a specific sandbox and switching data to offline to save the storage.
In regards to the backup and restore, for those who have a dual-write enabled environment – there is a one on one link between F&O and the data first environment.
If you are in a certain scenario where you want to store the production database in a sandbox – you have self-service actions for that. And, you won’t clean up dual-right configurations automatically.