Deployment & Environments Overview

This page covers general concepts around environments and deployment as they apply to organizations using SAVHN, and to integrations built against it. It's written at the level of best-practice guidance rather than internal infrastructure detail.

Environment concepts

Most SAVHN customers interact with two logical environments:

• Production — the live environment your organization's users work in day to day. Data here is real and business-critical.
• Staging/sandbox (where available on your plan) — an isolated environment for testing configuration changes, new integrations, or Automations before they touch production data.

If your plan includes a staging environment, it is a fully separate organization instance — its own data, its own API credentials, its own webhook registrations — not a read-only mirror of production. Changes made in staging never propagate to production automatically.

When to use staging

Use a staging environment (or request one, if your plan doesn't include it by default) before:

• Rolling out a new custom role or a broad permission change across many users.
• Enabling a module with irreversible-feeling side effects on data structure (e.g. enabling Payroll for the first time, which introduces pay-cycle-driven records).
• Testing a new integration's write behavior — especially anything that creates or modifies records — before pointing it at production credentials.
• Validating an Automations workflow that fires on a high-volume trigger (e.g. "on every new Ticket"), where a misconfigured condition could otherwise affect a large number of live records quickly.

Environment-specific configuration for integrations

If you're building an integration or automation that runs against SAVHN, treat environment configuration as first-class from the start:

• Separate credentials per environment. Never reuse a production API key in a staging build, and vice versa — generate a distinct key per environment from the Developer Portal so they can be revoked independently and so usage/rate-limit accounting doesn't mix.
• Separate webhook endpoints per environment, or at minimum a way for your endpoint to distinguish which environment an event came from (the orgId in the payload differs between your staging and production organizations).
• Externalize the base URL and org identifiers in your integration's configuration rather than hardcoding them, so promoting an integration from staging to production is a configuration change, not a code change.
• Never point a staging build at production credentials "just to test something quickly." This is the most common source of accidental production data changes from integration development.

A practical promotion checklist

Step	Staging	Production
Configure module/role changes	Make and verify here first	Apply only after staging verification
Generate integration credentials	Separate key, clearly labeled	Separate key, clearly labeled
Register webhook endpoints	Point at a staging/test receiver	Point at your production receiver
Run a smoke test of the full flow	Required before promoting	Repeat post-deploy to confirm
Monitor initial production traffic	—	Watch the webhook delivery log and API error rates for the first hours after go-live

Configuration you should externalize, not hardcode

Whether you're configuring an integration script, a scheduled job, or a webhook receiver, keep the following out of your application code and in environment-specific configuration instead:

Item	Why it belongs in configuration, not code
API base URL / organization identifier	Differs between staging and production; hardcoding forces a code change to promote
API credentials	Must be rotatable and revocable independently of a deploy
Webhook signing secret	Environment-specific; a leaked staging secret should not compromise production verification
Rate limit / retry tuning	You may deliberately want more conservative retry behavior in production than in staging
Feature flags for in-development integration behavior	Lets you merge code before it's fully validated, and turn it on per environment when ready

Treating these as configuration rather than code is what makes the staging-then-production promotion checklist above actually usable in practice — if a base URL is hardcoded, "promote to production" silently becomes "edit code and redeploy," which defeats the purpose of separating the environments in the first place.

General environment hygiene

• Naming discipline. Give staging and production API credentials and webhook endpoints unambiguous, consistent names so it's obvious at a glance which environment a given key belongs to.
• Access control mirrors production intent. Don't treat staging as a free-for-all just because the data is disposable — apply the same role-based access principles described in Role Management & Permissions so staging remains a reliable signal of how production will behave.
• Data freshness expectations. If your staging environment was seeded from a production export at some point, remember it will drift out of date; don't rely on staging data being current unless your organization has an explicit refresh process.
• Rate limits apply per environment independently — testing load in staging does not consume your production rate-limit budget, but also means staging performance under light test traffic isn't a reliable predictor of production performance under real load.

CI/CD considerations for integration code

If the integration or automation logic you're building lives in your own codebase (rather than being configured entirely inside SAVHN's Automations module), apply the same environment discipline to your deployment pipeline that you would for any service with external dependencies:

• Store SAVHN API credentials as pipeline secrets scoped per environment, never committed to source control or hardcoded in a script that might get copied between environments.
• Run integration tests against staging as part of your pipeline before a production deploy, using a dedicated staging API key reserved for automated testing so its usage pattern doesn't interfere with manual staging testing done by other team members.
• Treat a failed staging smoke test as a hard gate on promoting to production — the whole point of having a staging environment is to catch integration-breaking changes before they reach live business data.

Handling planned maintenance and downtime expectations

• SAVHN, like any actively developed SaaS platform, may have planned maintenance windows; if your integration is sensitive to brief unavailability, build reasonable retry-with-backoff behavior into write operations rather than treating a transient 5xx as a permanent failure.
• For scheduled batch jobs (e.g. a nightly export), avoid tightly coupling the job's timing to being the very first thing to run after a maintenance window — a small buffer reduces the chance of hitting the platform mid-restart.

Rollback and change management

For configuration changes made directly in the SAVHN admin console (roles, module enablement, workflow settings), there is no automatic environment-to-environment promotion mechanism — changes verified in staging must be manually re-applied in production. Keep a lightweight change log (even a simple document) of configuration changes as you make them, so a change can be manually reverted if it causes unexpected behavior, and so the same sequence can be replayed in production once verified.

Summary

Treat SAVHN environments the way you would treat environments for any business-critical SaaS platform: isolate credentials, verify changes in staging before they touch production, and keep configuration externalized so promotion between environments is deliberate rather than accidental. For the security implications of environment and credential separation, see Security & Compliance Overview.