Most integration problems are not hard, they are just invisible until a customer complains or finance finds a gap. Good logging and monitoring turns integrations from guesswork into something you can inspect, measure, and improve without living inside production consoles all day.
Why Integrations Are So Painful to Debug
Integrations sit between systems, which means they are usually blamed by everyone and owned by no one.
- The website team sees a form submit but no record in the ERP.
- The ERP team sees missing orders and assumes the website is broken.
- Operations sees inconsistent statuses across portals and back office screens.
When you do not have a clear integration log, every incident becomes a detective story across web servers, ERP traces, and email threads.
What to Log for Each Integration Event
Useful logging starts by treating each integration call as a first class event, not just a background detail.
At a minimum, each event should capture:
- Correlation ID: A unique identifier you can use across systems and logs.
- Timestamp: When the event started and when it completed.
- Source and target: Which system called and which system responded.
- Operation: For example, CreateQuote, UpdateCustomer, SyncInventory.
- Key business identifiers: Customer number, email, document number, or external IDs.
- Status: Success, Failed, or Retried with a count.
- Error information: Error code and a human readable message when something goes wrong.
You do not always need to store full payloads, but you do need enough context that someone in operations can recognize the record and trace what happened.
Logs for Developers vs Logs for Operations
One mistake is to assume that the only audience for logs is developers. That usually results in walls of stack traces and technical details that no one else can use.
A better split looks like this:
- Operational log: A table or dashboard that shows one row per integration event with status, business identifiers, and user friendly messages.
- Technical log: Deeper traces, stack traces, and raw payloads stored in log files or a dedicated logging system.
Operations and support teams should be able to answer basic questions without opening a code editor.
Database Tables vs Log Files vs External Tools
There is no single correct place to put logs, but each option has trade offs.
- ERP tables (for example, Business Central log or staging tables): Great for business centric views and joining with other ERP data.
- Website database tables (for example, WordPress custom tables): Useful for tracking inbound submissions and their integration status.
- Log files or cloud logging services: Best for high volume, low level traces and debugging information.
In practice, you often want a combination: summarized events in tables for humans, and detailed logs in files or a logging platform for developers.
Designing an Integration Log Schema
If you create a dedicated integration log table or entity, keep the schema simple and consistent across different flows.
- Log ID (primary key).
- Correlation ID (used by external systems and search).
- Source System and Target System.
- Operation Name (for example, QuoteIntake, CustomerSync).
- Business Key (customer number, email, document number, etc.).
- Start Time and End Time.
- Status and Retry Count.
- Error Code and Error Message (optional when successful).
Using the same shape for different integrations lets you build shared reports and monitoring, instead of one off tools for each flow.
Monitoring, Dashboards, and Alerts
Logging is only half the story. You also need a way to see patterns and get notified when something goes wrong.
- Dashboards: Show event counts over time, success rates, and top error types.
- Backlog indicators: Monitor how many events are stuck in New or Failed status for key flows.
- Threshold based alerts: Trigger alerts when failure rates exceed a threshold, when queues grow too large, or when specific critical errors appear.
- Environment awareness: Make it clear whether you are looking at production, staging, or development data.
These do not have to be elaborate. Even a simple table plus a scheduled email summary can dramatically reduce “surprise” failures.
Correlation IDs and End to End Tracing
Correlation IDs are one of the simplest tools you can add, and one of the most helpful.
- Generate a unique ID when a request starts on the website or API gateway.
- Include that ID in logs, headers, and ERP staging records.
- Return it in error messages to support or users when appropriate.
That way, when someone sends you a screenshot or ticket, you can search for one ID and see the full path across WordPress, middleware, and Business Central.
Logging in a WordPress and Business Central Integration
For a WordPress plus Business Central stack, a practical pattern looks like this:
- On the website: Log form submissions to a custom table with correlation IDs and basic status fields (Submitted, SentToERP, ERPConfirmed, Failed).
- In Business Central: Use staging tables for intake (for example, QuoteIntake, LeadIntake) with their own status and error fields.
- In the integration layer: Log each API call with correlation IDs, HTTP status codes, and response times.
- For operations: Provide pages or reports in both WordPress and Business Central where staff can search by email, customer number, or correlation ID.
This way, you can answer “what happened to this request” from either side without guessing.
Common Logging and Monitoring Mistakes
Even teams that attempt logging often fall into a few predictable traps.
- Too much noise: Logging every tiny detail without structure, making it hard to find signal.
- No retention policy: Keeping logs forever until storage or performance becomes an issue.
- No standard format: Each integration writes logs differently so tools cannot be shared.
- Production only: Logging that exists only in production, making it hard to debug in test environments.
- Alert fatigue: Alerts that fire constantly for minor issues, causing people to ignore them.
The fix is usually to simplify: fewer, better structured events, clear retention, and alerts tuned to real business impact.
How Elephas Approaches Integration Observability
At Elephas, we treat logging and monitoring as part of integration design, not an afterthought.
- We help define what “good enough” visibility looks like for your stack and your team size.
- We design log and staging schemas that line up with Business Central and your website’s data model.
- We implement correlation IDs and structured logging across WordPress, middleware, and Business Central.
- We add lightweight dashboards and alerts so you see integration issues before customers and auditors do.
The goal is simple: when something goes wrong, you can find out what, where, and why in minutes, not days, and you can fix it without guessing in production.
