10 don’ts when designing customizations in Microsoft Dynamics 365 Business Central
10 don’ts when designing customizations in Microsoft 365 Dynamics Business Central
All projects I've seen face the same, well-known triple constraint: quality, cost, and time.
When communicating with decision-makers or budget holders, I often hear that cost and time are the dominant constraints, which makes the functional and technical teams sit together, try to prioritize quality-related attributes, and cut on those that contribute the least to the solution value. Today, in this article I'll try to reflect on the compromises that can be mistaken for harmless time-savers, but which should be avoided at all times when designing customizations in Business Central.
1. Not allocating enough time to explore standard functionalities that are related to the customization
Microsoft Dynamics 365 Business Central provides a wide range of standard features and functionalities that cover the general needs of most companies. Using maximum of out-of-the-box functionality before considering customizations can be a great cost and time saver. Even if some specific features are missing and have to be built, my experience shows that Business Central usually offers open places where customizations can be harmoniously integrated with the rest of the system. It's not feasible to know this app inside out because it's extensive and subject to localization and evolving legal and industry standards. However, failing to invest time in understanding and leveraging these built-in capabilities can lead to:
- Creating unnecessary customizations and wasting budget.
- Using additional customization objects, resulting in extra licensing costs (applies to On-Premise licenses).
- Potential conflicts with existing features and data, which often leads to the abandonment of customizations in favor of standard features sooner or later.
- Missing the opportunity to be inspired by existing features, which can serve as a starting point for custom extensions.
2.Skipping essential documentation
I've heard multiple times that "documentation is not agile way, nobody needs it anymore". Let me respectfully disagree—we call documentation anything from project overview, functional specification, technical specification, user guides, support notes, to help center resources. While the trend is toward minimizing documentation (with classic user guides and help centers disappearing), it's still crucial to have some documentation in place. I firmly believe that a functional specification is the essential minimum for any customization project. It is not only a product of a thorough analysis to design a solution that solves a set of pain points or targets a customer has, but also serves as a form of a contract defining the project's scope transparently. The quality of this phase has an impact on the consistency of further customizations that will be done within Business Central. Moreover, it's an opportunity to challenge existing business processes, as during design review workshops it is not a rare case when a customer decides to abandon some of business workflows rather than try to facilitate them with Business Central customization.
Another reason for a functional specification is that even though customers and Business Central partners speak a common language, their backgrounds and understandings of concepts may differ. Instead of discovering issues after consuming time and budget, it's better to review wireframes and mockups, discuss, and correct supported scenarios upfront. This is nearly impossible through oral discussions followed by scattered notes and emails. Furthermore, after a year or two, especially if the team has changed, it becomes challenging for the customer and project managers to gather the scope and purpose of the customizations. This can make it harder to support, make further changes, or understand the reasons behind gaps between current customer expectations and implemented behavior.
3. Neglecting industry standards
When customizing Business Central, it's crucial to adhere to established rules and best practices widely accepted within a specific industry or country. This includes data privacy protection, tax regulations, data retention rules, audit trails, and more. Failing to do be alert to this matter may result in financial or reputational losses for customers.
In terms of the standards of Business Central as a system, it's essential to consider that taking customer requests as literal technical tasks may lead to system performance issues. Taking time to think through stable alternative solutions is always worth it, as customers shouldn't be held responsible for solutions that strain the system. This is why they have us, as their partners.
4. Starting the design process when knowing "99% of business scenarios"
During "What if" sessions, brainstorming all possible business scenarios can be a tiresome task for both customers and their partners. To expedite discussions, it's not uncommon to hear, "I think this covers 99% of our cases, so let's focus on them and discuss the rest after going live." However, it's a red flag indicating the need to spend more time with key users to discover the remaining 1% of cases. In my practice, we've encountered situations where further investigation revealed that those 1% represented a more substantial percentage and required a significantly different architectural solution. While customizations should be flexible enough to accommodate various scenarios, if some are not supported, both parties must have a clear understanding of what those are. This allows brainstorming on workaround procedures for these cases, prepares future key users, and saves customers from operational roadblocks when using new customizations.
5. Failure to review estimate consistency based on low vs. high fidelity specification
Customers often want to know the project budget before going with it, which is entirely reasonable. At this stage, a business analyst collects high-level requirements to provide an overview of the customization's purpose and scope (low-fidelity specification), based on which the estimations are prepared. Further, as details of the design are discussed and documented (high-fidelity specification), new features that were never mentioned in high-level analysis often surface.
It's essential to understand that 10-30% deviations between estimates based on low and high-fidelity specifications are normal and typical. In case the budget is a primary constraint, additional features can be postponed to later phases or removed from the specification. Failing to review the estimates based on the high-fidelity specification, however, will likely lead to these deviations being compensated with a decrease in the solution's overall quality, delivery delays, and a decrease in trust between the partner and the customer.
6. Disregarding tooltip
Tooltips may seem like minor details and are often disregarded in customizations. I understand why, as crafting concise yet meaningful tooltips demands time, skill, and budget. Nevertheless, the absence of tooltips contradicts the "less documentation" philosophy and prolongs the onboarding process for new users. Tooltips significantly enhance the user experience, reducing the need to interrupt mentors or seek support for clarification and training. If there isn't time for all fields and actions, at the very least, important and non-standard functions should have quality tooltips.
Do you find interesting articles from Xpand's experts? Read the latest story from Denys Fedorov, Leading Technical Writer of Xpand about technical writing for successful product launch.
Interested in reading more articles written by Anzhela Pozdniakova? Please read about Consolidation for Dummies or Tracking Intercompany Transactions, for example.
7. Ignoring naming conventions
Poor names, combined with missing tooltips, can create confusion for new users, hindering the adoption of new customizations. They don't have the luxury of time to learn the new language of customization names, which may sound foreign to them. Creating a meaningful name for an action or field can take some time, but it's always worthwhile if you want users to appreciate the customization. When building customizations in Business Central, it's essential to know of common field and function names in the system and reuse them when applicable. This helps users familiarize themselves with the standard Business Central actions and understand what a similar action does on a custom page.
8. Hardcoding data
Designing solutions with hardcoded values, such as static thresholds and limits, duration types, document reports, coded mapping between Business Central table fields and other system's table fields during integrations, may seem quicker. This approach eliminates the need to consider where to add setups or introduce a new page to accommodate that setup, name those fields, and create time-consuming tooltips. However, this "quicker" approach makes the system less adaptable and more susceptible to issues when variables and circumstances change. In practice, business data frequently changes due to various factors. We consider quality customization to be one that is flexible and supports changes in business data variables.
9. Not dividing customization into multiple MVPs
Except for new Microsoft Dynamics 365 Business Central implementations combined with major system customizations, it's always a good idea to follow an Agile approach and break down customer requests into encapsulated features, as well as delivering and going live with them separately. In any case, key stakeholders participating in discovery workshops, design review sessions, and UAT usually juggle these activities with their regular responsibilities.
Splitting Business Central customizations into small, independent parts reduces stress and ensures prompt feedback from stakeholders. If it's possible to go live with part of customization MVPs, it's highly recommended. The sooner a new customization goes live, the sooner the customer can benefit from their investment. The longer a new customization takes to go live, the less relevant it becomes, as we know that business and requirements evolve continuously.
10. Not considering existing workflows vs changing Business Central
Sometimes it is just a better idea to review business processes rather than adapt Business Central to them. This system has been on the market for decades, undergoing changes and adaptations that were triggered by industry trends and feedback from thousands of customers using it. Before thinking of tailoring custom functionality to specific twisted workflows, especially if this is a small business, it is a good idea to try to suggest customers tweak their workflows and try to apply the workflows that standard Business Central suggests. This approach may save the customer's budget on unnecessary customizations and help them discover changes that improve historically built processes.
Among other services related to Microsoft Dynamics 365 Business Central, such as add-ons development, upgrades from Microsoft Dynamics NAV to the latest Business Central versions, or implementation, Xpand provides services for creating customizations for your ERP system as well. If you need more information about this or any other of our services, please contact us or me directly via LinkedIn.