Skip to main content
SynaptaGrid Platform
← All capabilities
Available now

Platform capability · Organizations, Plans & Settings

Manage customers, plans and settings in one place

One record of every customer, app, plan and setting, with overrides for each customer

The platform keeps one record of your organizations, members, apps, app versions, plans, subscriptions, sign-in setup, notification rules, regions, jobs and settings. Your operators manage it in the operator console, and every platform service reads its settings from it.

Built in

What you get

  • Organizations, users, members, invitations and domains
  • Apps, app versions and the app instances each customer has installed
  • Plans, plan features, bundles of several apps in one plan, prices and subscriptions
  • Settings can be set for the platform, a region, an organization, an app instance or a single user. The most specific value applies
  • Compatible apps can use the platform as their OIDC sign-in provider, with each app registered and managed in one place
  • SCIM 2.0 provisioning for users and groups
  • Single sign-on set up for each organization (SAML, OIDC)
  • Sender addresses, email templates and notification settings
  • A list of the regions the platform runs in
  • Scheduled jobs and background tasks
  • Import an app declaration to add an app and its features
  • A marketplace of apps and their publishers
  • Support access for operators: an operator can act as a customer user, and each session is recorded
  • Operators can connect Claude or ChatGPT to look up customers, plans, alerts and audit records
  • Every group of settings has defined fields, so a misspelled or unknown setting is rejected
Under the hood

How it works

Settings apply from the whole platform down to one user

Settings are layered: platform defaults first, then region, organization, app instance and single user. The most specific value applies. Each layer starts empty, and an empty layer takes the value from the wider one. Your app reads the final value and does not need to know which layer it came from.

Unknown settings are rejected

Each group of settings has a fixed list of fields, and each field has a type. A change is saved as the whole group and checked against that list, so a misspelled name or a wrong type is refused. Two services cannot read the same setting in different ways.

One source of settings for every service

Every platform service reads its settings from this one place: feature switches, branding, single sign-on setup and more. Settings are not kept in separate files for each environment, so environments do not drift apart.

Pairs well with

Related capabilities

Sign-in & Identity

Every sign-in screen carries your brand

Authorization

Roles, attribute rules and resource hierarchies in one permission system

Billing & Subscriptions

Plans, prices, invoices and metered usage

App SDK

Register features, events, permissions, AI tools and infrastructure needs in one app declaration

Want a deeper walkthrough of Organizations, Plans & Settings?

A solution architect will demo the live service against your domain model.

Get a deployment assessment