Durable Workflow Orchestration
How do I contact Temporal sales for Enterprise/Mission Critical, and what should we prepare (APS/Actions, retention, regions, SSO/SAML, SLA)?
6 min read
Most teams only talk to sales when something is already on fire. For Enterprise and Mission Critical workloads on Temporal Cloud, you’re better off talking to us before you hit scale, strict SLAs, or compliance gates—so we can size and design the deployment correctly from day one.
Quick Answer: Contact Temporal sales via the “Get in touch” option on the Temporal Cloud page. For an Enterprise/Mission Critical conversation, come prepared with your estimated Actions per Second (APS), data retention needs, preferred regions, SSO/SAML requirements, and uptime/SLA constraints so we can quickly validate fit and size your deployment.
Frequently Asked Questions
How do I contact Temporal sales for an Enterprise or Mission Critical deployment?
Short Answer: Use the “Get in touch” flow on the Temporal Cloud page and indicate that you’re evaluating Temporal for Enterprise or Mission Critical workloads.
Expanded Explanation:
If you already know you’re running or planning critical workloads—payments, order fulfillment, ledgers, AI agents, infrastructure orchestration—go straight to Temporal Cloud and click “Get in touch” or “Sign up for Cloud.” In the form, note that you’re evaluating Enterprise/Mission Critical and briefly describe your use case and reliability constraints.
A Temporal specialist will follow up to validate your requirements, walk through architecture (Workers in your environment, Temporal Service in the cloud), and map your needs to appropriate quotas, retention, regions, and SLAs. We design for workloads where failures are guaranteed—crashes, timeouts, flaky networks—but execution still must complete with no lost progress.
Key Takeaways:
- Reach sales through the Temporal Cloud “Get in touch” flow.
- Mention Enterprise/Mission Critical and share a short description of your workflows and reliability needs.
What should we prepare before talking to Temporal sales (APS/Actions, data retention, regions, SSO/SAML, SLA)?
Short Answer: Have rough numbers and constraints ready: expected Actions per Second (APS), event/data retention windows, required regions, identity/SSO needs, and uptime/SLA targets.
Expanded Explanation:
Temporal is a Durable Execution platform. We size and price primarily around Actions (Workflow and Activity executions, signals, timers, etc.) and the durability/visibility guarantees you need. Coming in with directional numbers—even if they’re estimates—lets us quickly propose the right configuration instead of guessing.
Think about three axes: scale (APS and growth), time (how long Workflows and histories must be retained), and blast radius (regions, resilience, and SLAs). Add identity and access (SSO/SAML, RBAC) on top. With that, we can discuss whether you should start with a lower tier and ramp or go straight to an Enterprise/Mission Critical profile.
Steps:
- Estimate scale: Rough APS (average and peak), Workflow durations, and expected monthly Actions.
- Define durability & compliance: Required history retention, audit needs, and any regulatory constraints (e.g., data residency).
- List operational constraints: Preferred regions, SSO/SAML provider, uptime/SLA needs, and any change-management or security requirements.
How should we think about APS/Actions vs. other sizing inputs?
Short Answer: APS (Actions per Second) is the primary lever for sizing Temporal Cloud; retention, regions, and features then shape the profile around that baseline.
Expanded Explanation:
Without Temporal, you size by counting services, pods, and databases. With Temporal, the key unit is Actions: starting a Workflow, completing an Activity, firing a timer, sending a signal. That stream of Actions is what the Temporal Service reliably records, replicates, and replays so your code can pick up exactly where it left off after any failure.
APS tells us how much real-time throughput you need. Retention tells us how long execution histories and visibility must stick around. Regions tell us how far you need that durability and availability to extend (single region vs. multi-region, data residency). Taken together, they produce a realistic profile for performance and cost—without you over-provisioning a fleet of databases and brokers.
Comparison Snapshot:
- APS/Actions: Directly affects throughput, scaling behavior, and cost in Temporal Cloud.
- Other inputs (retention, regions, features): Shape durability, compliance, and resiliency around your APS baseline.
- Best for: Teams that want to pay for execution and durability, not idle hardware and over-provisioned infrastructure.
How do SSO/SAML, regions, and SLAs fit into an Enterprise/Mission Critical Temporal Cloud deployment?
Short Answer: SSO/SAML, regional placement, and SLAs define how your teams access Temporal, where your data lives, and what uptime/recovery guarantees we jointly commit to.
Expanded Explanation:
SSO/SAML is about how your humans and tools authenticate to the Temporal Web UI and APIs. Regions define where the Temporal Service runs and where event histories are stored and replicated. SLAs turn our reliability posture—built-in replication, disaster recovery, and high availability—into contractual guarantees around uptime and recovery targets.
Before the sales/architecture call, identify which identity provider you use (Okta, Azure AD, etc.), which clouds/regions you prefer, and what formal SLAs your business or regulators require. This gives us a starting point to discuss Temporal Cloud’s 11+ regions, HA architecture, and how our replication and DR strategy matches your own risk model.
What You Need:
- Your IdP details and any SSO/SAML requirements (SCIM, group-based access, mandatory SSO).
- Target regions / data residency constraints and any existing uptime/SLA standards you must meet.
How should we approach Temporal strategically for Enterprise/Mission Critical use (beyond the initial sales call)?
Short Answer: Treat Temporal as a core Durable Execution primitive, not just orchestration, and align it to your highest-risk, multi-step workflows where failures are currently creating orphaned processes and manual recovery work.
Expanded Explanation:
Temporal is built for the work that currently wakes you up at 3 a.m.: money movement, order fulfillment, infrastructure rollouts, long-running AI pipelines, and human-in-the-loop flows where lost state is unacceptable. Strategically, you want to start where failures are expensive and visibility is poor.
With Temporal, workflows automatically capture state at every step. When something fails—API, network, or service—the Workflow resumes from the last recorded event after replay. You set retry policies instead of coding them. You wait 3 seconds or 3 months without a cron job silently dying. And operators get full visibility in the Temporal Web UI to inspect, replay, and rewind. Temporal Cloud then gives you this reliability as a managed, consumption-based service with high availability, high scale (300k+ Actions/second), and built-in DR—without you running the control plane.
Why It Matters:
- Business impact: Fewer dropped steps, no orphaned processes, and no manual recovery runbooks for critical workloads.
- Execution velocity: Developers write business logic as code while Temporal handles state, retries, timers, and task queues in the background.
Quick Recap
To talk to Temporal sales about Enterprise or Mission Critical workloads, start at the Temporal Cloud page and use the “Get in touch” path. Come prepared with estimates for Actions per Second, data retention, region and residency needs, SSO/SAML requirements, and uptime/SLA targets. We’ll use these to design a Temporal Cloud deployment that gives you durable execution, high availability, and full visibility into your critical workflows—without you building another brittle state machine or over-provisioned control plane.