Not every requirement belongs in Business Central, and not every feature belongs on your website. This guide gives you a simple way to decide where logic should live, so you avoid performance issues, upgrade pain, and integration chaos.
Two Places to Put Logic, Business Central and the Web Layer
When new requirements show up, most teams default to one of two instincts:
- Put it in Business Central so it is centralized and controlled.
- Put it on the website so you can ship faster and avoid touching ERP.
Both instincts are valid in some situations and dangerous in others. The right answer depends on what the logic does and who depends on it.
Questions to Ask Before You Decide
Use these questions as a quick triage before you open Visual Studio Code or the WordPress editor.
- Is this logic core to financial accuracy or compliance? If yes, it usually belongs in Business Central.
- Does it change how customers or prospects interact with you online? If yes, it often belongs in the website or portal first.
- How often is this likely to change? Fast changing rules are often easier to maintain in the web layer.
- Does this need to work even if one system is temporarily unavailable? That may imply a decoupled or staged approach.
- Who owns and understands this logic day to day? If it is owned by finance or operations, keeping it in Business Central may make support easier.
When Customizing Business Central Makes Sense
Customizations or extensions in Business Central are usually the right choice when the requirement touches core business rules.
- Pricing and discount rules that affect invoices and revenue recognition.
- Approval workflows for purchases, credit limits, or contract terms.
- Posting routines and dimension logic that feed your financial reporting.
- Validation rules that must apply no matter where the transaction starts.
In these cases, pushing the logic into Business Central keeps your system of record consistent. However, it also means you need to be careful about performance, licensing impact, and future upgrades.
When Customizing the Website or Portal Is Better
The web layer is usually the right home for logic that is about user experience, data capture, or presentation.
- Dynamic forms that adjust questions based on user choices.
- Guided steps for quote requests, onboarding, or service tickets.
- Customer portals that show Business Central data but present it in business friendly language.
- Marketing landing pages that need fast iteration and A/B testing.
Here, you can keep Business Central lean by treating it as the system of record, while using WordPress or another web front end to experiment and refine the experience.
Patterns for Sharing Logic Safely
Some requirements span both worlds. In those cases, patterns matter more than location.
- Shared configuration: Store rate tables, tax rules, or other configuration in one place, and have both Business Central and the website read from it.
- Validation in stages: Do basic validation on the website, then enforce final rules in Business Central before posting.
- APIs and staging tables: Use APIs to send data into Business Central staging, where more complex logic runs, instead of duplicating everything.
- Feature flags: Introduce new behaviors behind flags so you can roll them out gradually across systems.
How to Avoid Over Customization
The risk on the Business Central side is over customization. The risk on the website side is rebuilding half of your ERP in PHP or JavaScript.
- Prefer configuration and extensions over code that changes core objects.
- Be suspicious of requests that essentially replicate standard functionality with cosmetic differences.
- Document custom rules and where they live so future changes do not create conflicts.
- Review customizations at least once a year to decide which to keep, simplify, or retire.
A Simple Decision Matrix
If you want a quick rule of thumb, start here.
- Financial truth and compliance: Business Central first.
- Customer experience and lead capture: Website or portal first.
- Operational workflows that span both: Shared patterns with staging tables and APIs.
When in doubt, design the data flow and approval path on a whiteboard, then decide where each decision point belongs.
How Elephas Approaches This Decision
Because Elephas works on both Business Central and web platforms like WordPress, we are not motivated to push everything into one side. Instead, we help you:
- Clarify what really needs to live in Business Central and what is better handled in the web layer.
- Design web experiences that respect the rules enforced by your ERP, instead of fighting them.
- Use integration patterns that keep systems decoupled but consistent, such as staging tables and event driven updates.
- Plan for upgrades and future changes from day one, so today’s decisions do not become tomorrow’s blockers.
The result is a cleaner split between systems, fewer surprises at upgrade time, and a stack that can evolve without constant rewrites.
