SynaptaGrid Portal documentation

1. 01

   Complete onboarding

   Confirm the organization details, selected plan and data region. If checkout is required, the success page returns you to the same onboarding flow.

2. 02

   Review the dashboard

   Use the checklist and summary cards to see which account, member, subscription and application steps still need attention.

3. 03

   Set organization details

   Add the organization name, contact details, logo, domains, timezone and other settings your role is allowed to change.

4. 04

   Check your own profile

   Keep personal name, timezone, password and account preferences separate from organization-wide settings.

• Grant the narrowest role that supports the person’s work; product and administration permissions are separate.
• Use groups for access that follows a department, review board or operating team.
• Treat custom roles as organization-owned. Application releases do not overwrite them.
• A role can be scoped to an application instance, so access to one tenant application does not imply access to every instance.

Members edit their own profile fields and the organization fields marked as self-editable from their profile page; fields the organization manages are shown there read-only. An administrator holding member management permission edits every field for a member, including the manager, employee number and cost center, from the member profile. Every save is validated: an unknown field, a value of the wrong type, a choice outside the defined options or a missing required field is refused with a message that names the field, and nothing is stored.

1. 01

   Open Settings, then User attributes

   The page is visible to any member and editable only with the schema management permission.

2. 02

   Define a field

   Give it a code (lowercase letters, digits and underscores, fixed after creation), a label, a type and optional help text and display order.

3. 03

   Choose the type

   Text, whole number, decimal, yes/no, single choice, multiple choice, date, web address or email address. Choice types take a list of options.

4. 04

   Decide who may set it

   Mark it required if every member must carry a value, self-editable if members may change their own value, and available to access policies if roles and permissions may depend on it.

5. 05

   Retire it when it is no longer needed

   Deleting a field hides its stored values rather than erasing them; restoring the field shows them again. Use Show deleted fields to find and restore one.

• Values marked available to access policies can be referenced by a role or permission rule, so access can follow a region, a cost center or any field you define.
• A field is retired, never renamed. To change a code, define a new field and migrate the values.
• SynaptaGrid operators can view your field definitions and members’ values but cannot edit them; only your organization does.
• A request to erase a member’s personal data clears all of these fields and removes the member as anyone else’s manager.

1. 01

   Choose an application

   Open Marketplace, review the product and confirm it is available under the organization’s plan and region.

2. 02

   Provision an instance

   Start provisioning and follow the instance status. Do not repeatedly submit while the first request is still running.

3. 03

   Review the instance

   Inspect version, status, launch URL and the controls available for that specific application instance.

4. 04

   Apply instance settings

   Change the manifest-driven settings and overrides exposed to your role. Secret values remain masked after they are saved.

5. 05

   Launch the product

   Open Data or Automation from the ready instance. The organization and application-instance context travel with the launch.

1. 01

   Save the provider configuration

   Use Organization settings for the identity-provider identifiers, endpoints, certificates, directory connection or SCIM controls.

2. 02

   Copy the Portal-side values

   Give the identity administrator the displayed SAML service-provider metadata or the SCIM endpoint and newly issued bearer token.

3. 03

   Validate the connection

   Use Test connection for LDAP. For SAML or SCIM, verify with a controlled user before relying on the integration for the wider organization.

4. 04

   Roll out deliberately

   Communicate the cutover and keep a tested recovery path until the customer confirms normal access.

• Create an API key with only the actions and application context the consumer needs.
• Copy a new or rotated secret immediately. Portal does not reveal the plaintext again.
• Use separate keys for separate integrations; do not share one organization-wide key.
• Create webhook subscriptions only for the events the receiver processes.
• Inspect the subscription and delivery state before retrying or changing the destination.
• Rotate credentials before ownership changes or expiry, then revoke the previous value after the consumer has moved.

1. 01

   Provision both products deliberately

   Provision the production Data and Automation instances separately. Wait for each asynchronous request to reach ready and record each launch URL and application-instance identifier.

2. 02

   Create the operating group

   Create an Integration operators group, add the named maintainers and assign only the product roles they need, scoped to the production application instances.

3. 03

   Issue one credential per caller

   Open each product’s integration screen. Create a Data key for record read/write and an Automation key for the specific workflow start/read actions; store each plaintext once in the caller’s secret manager.

4. 04

   Subscribe the receiver

   Create only the required outbound event subscriptions, save the signing secret in the receiver and allowlist the exact event types and sources.

5. 05

   Prove the complete path

   Create a controlled Data record, start or trigger the workflow, use test delivery, inspect the delivery log and confirm the receiver deduplicates a repeated event.

6. 06

   Transfer ownership

   Give the operating team coordinates, grants, expiry, secret-manager references, test evidence, recovery instructions and the correlation identifiers. Never put the plaintext secrets in a ticket or handoff document.

• Review AI credit balance, allocations and usage before increasing access or purchasing more credits.
• Configure supported model keys and MCP connections only for the organization or user scope intended.
• Grant an AI agent at organization level before assigning its allowed tools to individual users.
• Use corpora for governed knowledge sources and verify who can query each one.
• Create a support ticket with the affected product, application instance, time and visible error.
• Use the knowledge base for known procedures and the ticket timeline for the authoritative support record.