Corrigo Field Service Management Support

Getting Help When Your Corrigo Install Isn't Behaving

Corrigo's support queue is one of those things that looks fine on a dashboard until you're standing in a client's building and the tech hasn't gotten their dispatch notification on a job they left the yard for two hours ago. I've worked with Corrigo deployments long enough that I've seen the same three problems repeat in different industries. Here's what actually works when you need help and what you should know before you open a ticket.

Corrigo Field Service Management Support Channels

Corrigo offers support through a few different paths and which one you use matters more than most people realize. The primary channel is their online support portal where you submit tickets with attached logs and screenshots. Then there's phone support during business hours depending on your contract tier. If you're on an enterprise agreement you might have a dedicated account manager who can escalate faster than the general queue. There's also a community forum and documentation library that handles a surprising number of issues without any human involvement. I learned the hard way that the community forum is basically unmoderated and often points you toward documentation that was written for version 9 when you're running something newer. Don't waste an hour there. Use it to search for error codes or specific integration names, then move to the official portal if you're stuck. One thing nobody tells you about opening a ticket: include your environment ID and the specific module affected in the first line. Support reps see hundreds of requests a day. "It's broken" versus "Work order WO-2024-00847 in the Preventive Maintenance module won't save changes after the 5.2 update" changes how fast you get a useful response. I've watched identical problems get resolved in four minutes versus two days based entirely on how the initial ticket was written.

Here's a practical edge case that still comes up. We had a client whose Corrigo integration with SAP broke after a routine quarterly patch. Work orders were flowing from SAP to Corrigo but status updates weren't reflecting back. The support team's first instinct was to check the Corrigo side and spent three days running diagnostic scripts there. I'd spent years watching these bidirectional syncs and I knew the issue was almost always the IDOC processing on the SAP side, not the outbound payload from Corrigo. I asked specifically to involve someone who understood the SAP PI/PO layer and within twenty minutes we found a mapping table entry that had been reset during the patch. The workaround was straightforward but only if you're looking in the right place at the right time. Most support queues just don't have that kind of cross-platform expertise on standby for mid-tier contracts.

How to Navigate a Support Interaction Efficiently

The first step is knowing your deployment type. Corrigo has cloud and on-premise versions and support handles them differently. Cloud deployments get faster turnarounds because the team has direct database access. On-premise instances require you to gather logs yourself first and sometimes deal with longer response times because they can't reach into your environment. Check your contract details in the Corrigo dashboard before you call support so you know what you're actually entitled to. Before opening any ticket, run through these checks. Confirm the issue reproduces consistently. Take screenshots with timestamps. Export any relevant audit logs. Note the browser and device being used. List out what changed recently in the environment. These five things alone will cut your initial back-and-forth to a fraction of what it normally takes. I tracked my own ticket resolution times over six months and the average dropped from three days to roughly eighteen hours once I started including all of that in the original request. There are some things you should understand about how Corrigo support is structured internally. The first level team handles about sixty percent of requests that come in. Those are usually permission issues, basic configuration questions, or known bugs with published workarounds. If your problem survives first level it goes to a deeper tier where engineers actually look at the code paths. This is where patience matters. Second tier tickets often get assigned to someone who specializes in integrations or someone who knows the scheduling engine specifically. You won't know who your engineer is until day two or three usually.

A counter-intuitive thing about Corrigo: the field tech mobile app causes more support tickets than any other module despite being the most used part of the platform. This is because the mobile environment behaves differently from the web interface. Offline mode, push notification delays, and geofencing mismatches create errors that don't appear in any logs the way a support rep expects. If your techs are reporting app problems, don't just submit a general ticket. Be specific about whether the tech was on cellular or Wi-Fi, what the last successful action was, and whether the device showed an offline icon at the time of the failure. That information gets routed to someone who actually understands the mobile architecture instead of getting bounced around general support. Another nuance that trips people up is how Corrigo handles data retention. Support can pull records that are ninety days old but anything beyond that usually requires a separate data recovery request that goes through a different team with different SLAs. I've seen clients waste two weeks trying to get log details from a three-month-old incident because they didn't realize they needed to route that request separately. Save your incident logs locally for at least a year. Corrigo won't keep them for you unless you've configured custom retention policies.

When Support Won't Help and What to Do Instead

There are scenarios where Corrigo support will flatly tell you they can't resolve your issue. This usually happens with custom integrations that use unsupported API endpoints or third-party connectors built outside the Corrigo partner ecosystem. They'll give you the REST API documentation and say go from there. If you're deep in a custom build and hit a wall, the workaround is to engage a certified Corrigo implementation partner rather than continuing to escalate through general support. These partners have access to internal resources that public-facing support doesn't, including earlier access to patches and the ability to request specific engineering attention. Another area where support hits limits is performance troubleshooting across your entire instance. They'll run diagnostics on individual components but won't typically investigate slow query patterns that span multiple tables or custom fields you've added. For that kind of issue you either need someone who understands the underlying database schema well enough to read the execution plans yourself, or you need to bring in an architect who can map your customizations against the base Corrigo structure. I've seen this exact problem resolve in about an hour once we got someone in who'd built two or three Corrigo deployments from scratch. The bottleneck was always a custom field that was supposed to be indexed but wasn't, combined with a report pulling unaggregated data across five thousand records. Support reps don't get paid to do SQL forensics. If you're on a basic support plan and waiting times are becoming a real operational problem, there are ways to improve your position. Consider upgrading to a higher support tier that includes faster response SLAs. This is particularly worth it if you run a large fleet of field techs or if downtime directly impacts revenue. The cost difference between standard and priority support is usually measured in the low thousands per month and can save ten times that in lost productivity during critical incidents. Another approach is building a knowledge base of your own issues and solutions. Document every ticket you submit and every workaround you apply. Over time this becomes invaluable for your own team and can sometimes be referenced when re-opening a ticket to show that a previously reported problem has recurred.

For smaller organizations that can't afford premium support tiers, the self-service documentation is actually pretty thorough if you know how to use it. The Corrigo knowledge base covers most configuration scenarios and the release notes document known issues for each version. Cross-reference your version number with the latest patch notes and you'll often find your problem listed with an expected fix date before support even responds to your ticket. This has happened to me several times. The ticket stays open while I'm reading the patch notes and find the workaround in section three under known limitations. The one area where I'd recommend stepping away from Corrigo's built-in support entirely is for complex multi-tenant or white-label deployments. Those configurations have their own support track and general support teams often don't have the context to help. If your deployment involves custom branding, tenant isolation, or reseller configurations, make sure you're talking to the right team from the start. Otherwise you'll spend weeks going in circles with people who genuinely don't have access to the information needed to help you. Most importantly, treat your support relationship as something you manage rather than something that manages you. Follow up proactively. Ask for escalation when things aren't moving. Keep a paper trail. The support organization at Corrigo works fine when you're clear about what you need and when you push reasonably hard. It falls apart when you assume they already know the context of your specific situation. They don't. Nobody at that organization knows your business. You have to bring that to every single interaction.