Integration maintenance doesn't have to hijack your engineering team. By providing execution logs to support teams, streaming alerts into existing observability tools, and empowering CS with low-code configuration tools, you can route routine tasks to non-devs. Combine this with embedded customer self-service for configs and allow engineers to focus on the things that require their expertise.
Part one of this series covered how the right architecture prevents a lot of integration maintenance from being needed. But prevention only gets you so far. Credentials will still expire. A customer will still need a field mapping updated to match a schema change. A sync will still fail on a weekend. Now, the questions are "Who handles them when they happen?" and "Does it need to be an engineer?"
Most of the time, engineering shouldn't be needed for routine maintenance. The right platform lets support teams, CS, and even customers themselves resolve most issues without pulling engineering into the mix.
Give visibility to everyone, not just engineering
One of the fastest ways to overload engineering is to make them the only people who can tell whether an integration is performing as it should.
Support gets a ticket. Support asks engineering for help. An engineer opens the logs, reproduces the issue, and discovers that a customer's credentials expired three days ago. The fix takes thirty seconds. But the interruption takes 30 minutes plus whatever time is necessary to context switch.
A platform that minimizes maintenance makes pertinent information available to whoever needs it, not just engineering. This means:
- Step-by-step execution logs, with the exact input and output at every stage
- Searchable run history and error rates
- Detailed monitoring dashboards
- Alerting, so your team hears about a failure before a customer does
When support or CS can see that a run failed because a token expired, they should be able to resolve the issue directly.
Don't let the platform become a silo
Your engineering team already has an observability stack – something they've built dashboards and alerting workflows on. An integration platform that doesn't feed into that stack creates more work for engineers.
Look for a platform that streams logs and alerts into the tools you already use. That way, issues that require engineering attention show up where they are expected (and follow the same escalation paths) instead of living in an entirely separate process.
Let non-engineers own the routine work
Most integration issues don't need a dev. When a field mapping needs adjusting, a new customer instance needs deploying, or a schedule needs to change, does your platform let someone other than an engineer handle it?
Look for a platform with:
- A low-code designer that non-devs can use, not a toy that only covers the simplest cases, and not something so technical it's low-code in name only
- Tenant-specific configuration, so CS can map a customer's custom fields or adjust an instance's settings without asking engineering to ship a fix
- Role-based permissions so that these changes can be made safely, within clear boundaries, without an engineering review
This doesn't remove engineering from the picture. But it does route non-engineering work to the right people. Engineers should be writing new business logic and solving problems the platform hasn't seen before. They shouldn't be the ones updating a customer’s integration field mapping.
Let customers solve the simplest problems themselves
The cheapest support ticket is the one that's never filed. A large share of integration issues aren't bugs at all. Instead, they come from an expired API key, a revoked OAuth permission, or a webhook a customer mistakenly disabled. None of that requires engineering, or even support, if the customer has the access and capability to fix it themselves.
Look for a platform that lets you embed:
- A customer-facing management UI, inside your own product, where customers can see integration status and history
- Self-service credential management, so when a token expires, the customer is prompted to reconnect it directly
- Visibility into their own execution history, so a customer wondering why a sync failed can check it themselves
A customer who can reconnect their own Salesforce credentials in thirty seconds won't need to generate a ticket, let alone request an engineering escalation. Multiply that across your growing customer base, and self-service stops being a nice-to-have and becomes the most direct way to reduce integration issues.
A checklist for evaluating delegation and visibility
Operations
- Can support or CS investigate a failure without engineering?
- Are logs searchable, and do they show full request/response detail?
- Can logs and alerts stream into the observability tools we already use?
Non-engineers
- Can non-engineers configure and deploy known integrations without a pull request?
- Are permissions granular enough to support this safely?
Customers
- Can customers reconnect their own expired credentials?
- Can they view their own execution and error history?
- Can they retry a failed execution themselves?
If an integration platform vendor can't answer these confidently, engineering will remain the default owner of problems that don't require an engineer. And that ownership will only become more expensive over time.
Defining the right owner for every issue
You can't prevent every integration issue. So, the goal is making sure each one lands with whoever can resolve it most efficiently – often support, sometimes the customer, and, occasionally, an engineer. Combined with the architectural prevention covered in part one, this is what keeps integration maintenance from tying up your engineers when they should be working on something more critical to your business.
Ready to see what that looks like in practice? Start a free trial and see how Prismatic keeps integration maintenance off your engineers' plates.
