Troubleshooting Module & Integration Issues

This guide covers troubleshooting for module visibility and configuration problems, and for integration/API errors once authentication itself is confirmed working (if login or token issues are the problem, see Common Login & Access Issues first).

"A module isn't appearing for anyone in the organization"

Work through these checks in order — they're ordered from most to least common cause:

1. Is the module enabled? Go to Admin Console → Modules and confirm its state. If it shows as not enabled, this explains the issue for every user regardless of role — enable it from the Marketplace.
2. Was it recently disabled? Check the audit log for a recent disablement event; a module that "used to work" and stopped is more likely to have been intentionally or accidentally disabled than to be a platform bug.
3. Is a dependency missing? Some modules silently fail to fully function (rather than disappearing entirely) if a dependency was disabled after the fact. Check Module Marketplace: Enabling & Configuring Modules for the dependency table and confirm the required upstream module is still enabled.
4. Is this actually a permissions issue affecting everyone coincidentally? If a role was recently edited and that role is broadly assigned, it can look like a module-wide outage when it's actually a permission regression. Check whether the affected users share a role that was recently modified.

"A module isn't appearing for one specific user"

This is a permissions problem, not a module problem — see Common Login & Access Issues for the role/override diagnostic steps. If the module is confirmed enabled at the org level and other users on the same role can see it, the issue is almost always a user-level override.

"I enabled a module but its dependency-driven features aren't there"

Example: you enabled Fee Invoices but can't generate an invoice against an enrollment.

1. Confirm the dependency module (Enrollments, in this example) is not just enabled but has actual configured records — an empty but enabled dependency won't produce usable results.
2. Confirm the dependent module's own configuration is complete (e.g. Fee Invoices requires at least one Fee Structure configured before invoices can be generated against a program).
3. Re-check the dependency table in Module Marketplace: Enabling & Configuring Modules — some dependencies are "one of several," not strictly one specific module (e.g. Client Portal needs Projects or Finance, not necessarily both).

Disabling a module unexpectedly breaks a dependent module

If you disable a module that others depend on, the Marketplace warns you before confirming, listing affected modules. If a dependent module was disabled anyway (intentionally, accepting the disruption) and now needs to be restored:

1. Re-enable the upstream dependency.
2. Re-enable any dependent modules that were auto-disabled or left non-functional.
3. Expect to manually resume any workflow that was mid-flight when the dependency was removed — automatic resumption isn't guaranteed across a dependency gap.

API and integration troubleshooting

Requests failing with 4xx/5xx

Symptom	Diagnosis steps
400 Bad Request	Validate your JSON payload against the expected schema for that endpoint; check for missing required fields or wrong types
403 Forbidden on a specific domain	Confirm both that the module is enabled for the org and that the token's identity has permission for that domain/action
404 Not Found on a domain you expect to exist	Confirm the module is enabled; also double check the path — API domains match module keys exactly (e.g. client-portal, not clientportal)
409 Conflict	Usually a uniqueness constraint (e.g. duplicate email on a Lead) — check whether the record already exists before retrying blindly
422 Unprocessable Entity	Request is well-formed but violates a business rule (e.g. trying to approve an already-approved leave request) — check the current state of the resource
500 Internal Server Error	Retry once after a short delay in case of a transient issue; if persistent, capture the request ID (if returned) and escalate to support

Webhooks not arriving

1. Check Developer Portal → Webhooks → [endpoint] → Delivery Log first — this tells you whether SAVHN attempted delivery and what response your endpoint returned, which immediately separates "SAVHN never tried" from "your endpoint rejected it."
2. Confirm your endpoint is publicly reachable and returns a 2xx status promptly; slow endpoints can appear to "not receive" webhooks if they're timing out before responding.
3. Confirm the endpoint is still subscribed to the specific event type you expect — event subscriptions are opt-in per type, not all-or-nothing.
4. Check whether your endpoint's TLS certificate is valid and current; SAVHN will not deliver to an endpoint with certificate errors.
5. If delivery attempts show in the log with a non-2xx response, the problem is on the receiving end — check your endpoint's own logs for what it did with the request.

Integration writes succeed but data looks wrong downstream

• Confirm you're targeting the correct environment (staging vs. production) — see Deployment & Environments Overview; this is one of the most common sources of "my data isn't showing up" confusion.
• Confirm the identity behind the API credential has the record-level scope you expect — a write can succeed (201 Created) while still being scoped in a way that makes it invisible to a different user checking the UI (e.g. created under a different owner than expected).

Automations that stop firing or fire unexpectedly

1. Confirm the automation is still enabled — Automations can be individually paused without deleting them, and a paused automation produces no error, just silence.
2. Check whether its trigger module or referenced fields still exist — if a custom field or status an automation's condition depends on was renamed or removed, the automation may silently stop matching rather than erroring loudly.
3. Check the automation's run history (most automation builders expose a per-run log) to see whether it's firing but failing partway through an action, versus not firing at all — these have different causes and different fixes.
4. Watch for unintended fan-out — an automation with an overly broad trigger condition (e.g. "on every Ticket update" rather than "on Ticket status change to Escalated") can fire far more often than intended, which looks like a bug but is a configuration issue.

Data appears in the API but not in the UI (or vice versa)

• Confirm both are looking at the same environment — a script pointed at production while you're viewing staging in your browser (or vice versa) is a common and easy-to-miss cause.
• Confirm record-level scoping isn't the explanation — an API credential belonging to a broadly-permissioned identity can retrieve records that a specific UI user, viewing with their own narrower role, would not see.
• For real-time computed fields (see Platform Architecture Overview), confirm you're not comparing a cached UI view against a freshly computed API response, or vice versa, taken at different moments — a status that changed between the two reads is not a bug.

Escalation checklist

Before escalating an integration issue to support, gather:

• The exact endpoint, HTTP method, and a redacted copy of the request/response.
• The status code and error body returned.
• Whether the same request works against staging vs. production (isolates environment-specific config issues).
• The webhook delivery log entry, if the issue involves a missing webhook.
• Confirmation of which module(s) and dependencies are enabled for the organization.

This information typically resolves the issue without needing further back-and-forth, since the majority of module and integration issues trace back to enablement, dependency, or permission state that's directly visible in the Admin Console and Developer Portal.