Understanding Your Plan Limits
Your Survanta plan is controlled by subscription access plus one canonical Limit dictionary. The active catalog contains 17 keys: 13 numeric quotas and four Boolean capabilities represented as 0 or 1.
The two-part model
| Control | Question it answers | What it depends on |
|---|---|---|
| Subscription / time access | Can my organization use the platform at all right now? | Your subscription status and dates (and whether the platform admin has suspended the tenant). |
| Usage limits | How much can my organization use while the subscription is active? | The numeric limits attached to your plan (surveys, responses, users, storage, tokens, and more). |
Both must be satisfied for an action to succeed. If your subscription has expired or your organization is suspended, usage limits no longer matter — access is blocked first. While your subscription is active, usage limits decide how much you can do.
For full details of the time/access side, see Subscription Dates and Tenant Access.
How limit values work
Each limit on your plan is a number, and a few special values are worth knowing:
| Value | Meaning |
|---|---|
A positive number (for example 25) |
The maximum allowed. When you reach it, new usage of that type is blocked. |
-1 |
Unlimited only when that Limit's persisted minimum/maximum bounds explicitly allow -1; do not assume every key supports it. |
0 or not set |
Boolean capability 0 is off. Numeric behavior is guard-specific: user, storage, token, and integration paths grant no capacity, while current survey, response, and per-file-size guards apply no positive cap. Use the dedicated limit page. |
What quota checks do
- Most quota checks block a new write without deleting domain data.
- Credential quotas are an explicit exception on downgrade: access-token and integration-client reconciliation retains the oldest allowed active credentials and revokes newer excess records. Expired credentials do not consume capacity.
Limits at a glance
| Area | Limits | Status |
|---|---|---|
| Surveys | Maximum total surveys, maximum active surveys | Enforced |
| Responses | Maximum responses per period | Enforced |
| Users & storage | Maximum users, maximum storage | Enforced |
| Public links & tokens | MaxPublicSurveyLinks shared by links/QR, MaxPortalTokens, MaxViewerTokens |
Enforced |
| File uploads | MaxFileUploadSizeBytes; CanCompressFiles is a separate Boolean capability |
Enforced |
| Integrations | Maximum API integration clients | Enforced |
| Exports & portal | CanExportExcel capability; portal-token capacity plus normal active-survey rules |
Enforced through active keys; retired monthly/portal-specific keys are not used |
Approved future exception: survey version history
The active catalog still contains 17 keys. A planned eighteenth key, MaxSurveyVersionsPerSurvey, is approved but not yet seeded or enforced. Unlike current survey guards, this key has an explicit contract: missing or 0 disables customer-visible Version History/Restore, 1..50 sets the visible/restorable count including current, and -1 is invalid. It will not gate runtime contentHash or full refresh.