Spark ERP Docs

Appearance

Administration and DevOps overview ​

The Administration branch of the Studio Explorer groups the screens that operate a tenant: health and audit views, backups, background jobs, approvals, tenant-wide settings, data loading, and moving a tenant or its customizations between regions and environments. The DevOps branch holds the extension (plugin) manager. This section is the reference for every screen in both branches. It goes deeper than the short overviews in Monitoring and troubleshooting, Job and Scheduler Designer, Testing, Deployment, Versioning and release management and Code extensions.

Where to find it ​

Studio Explorer: Workspace > Administration and Workspace > DevOps. The definition of both branches is administrationBranch() and devOpsBranch() in frontend/packages/studio-core/src/metadataTree.ts. Each Explorer node opens one screen identified by a page key (the Studio view kind). Every screen also appears in the command palette under Go to.

Screen map ​

Explorer pathPage keyReference
Administration > MonitoringmonitoringMonitoring
Administration > Loggingaudit-logLogging
Administration > BackupbackupsBackup
Administration > System Settingssystem-settingsSystem Settings
Administration > JobsjobsJobs
Administration > My taskstask-inboxMy tasks
Administration > Notification templatesnotification-templatesNotification templates
Administration > Data importdata-importData import
Administration > BrandingbrandingBranding
Administration > Platform dictionaryplatform-dictionaryPlatform dictionary
Administration > API rate limitsrate-limit-settingsAPI rate limits
Administration > Read replica routingread-replica-settingsRead replica routing
Administration > Tenant migrationtenant-migrationTenant migration
Administration > Environment promotionenvironment-promotionEnvironment promotion
Administration > Test / QA casestest-casesTest / QA cases
Administration > Chat flowschat-flowsChat flows
DevOps > ExtensionsmarketplaceExtensions

The other DevOps nodes (Source Control, Build, Deployment, Packages) are shown as "coming soon" in the Explorer and are not available in this release.

Key concepts ​

TermMeaning
TenantOne customer organization. Every request carries the tenant in the X-Tenant-Id header and the acting user in X-Actor. All Administration screens operate on the tenant of the current Studio session.
Tenant scopeThe screen reads or writes only the current tenant's data (audit events, jobs, backups, notification overrides, branding, rate-limit override, test cases, chat flows).
Platform scopeThe screen shows or changes something shared by all tenants. In this branch only the Operational Config block of Read replica routing is platform-wide. Environment promotion and Tenant migration span tenants or regions but are invoked from a tenant session.
ArtifactA versioned, tenant-owned definition with the lifecycle draft, published, deprecated, archived. Test / QA cases and Chat flows are artifacts. See Versioning and release management.
Privileged actionAn action that is denied unless the actor holds one of the roles STUDIO_STAFF, TENANT_OWNER or TENANT_ADMIN, or has been granted the permission explicitly. Backup and Monitoring (platform numbers) use this gate.

Permissions at a glance ​

The screens do not apply a client-side gate except Extensions; the server decides. A denied call surfaces as an error banner on the screen.

ScreenResource and action checked by the serverCheck type
Monitoringadmin.monitoring / view (Platform panel); integration.flow / view; communication / view; integration.webhook / view. Jobs numbers: no permission check.Panels degrade independently: a denied panel reads "Not available to you".
LoggingNone checked by the audit endpoints.Open to any caller routed to the tenant.
Backupadmin.backup / view (list), admin.backup / manage (back up now, verify)Privileged action gate
System Settings, Brandingbranding:tenant-settings / update (write). Read is open.Permission resolver
JobsNone checked by the job endpoints.Open to any caller routed to the tenant.
My tasksCandidate approver of the task; workflow:<name> / approve, reject or returnPermission resolver
Notification templatesAUTHOR on artifact type notification-template (write). Read is open.Authoring policy
Data importNone checked by the import controller; each row is created through the Entity Engine, which applies the entity's own rules.Entity rules
Platform dictionaryEDIT_TRANSLATIONS on translation (write). Browse is open.Authoring policy
API rate limitsrate-limit:tenant-policy / update (write). Read is open.Permission resolver
Read replica routingread-replica:tenant-policy / update (write). Operational config endpoints: none checked.Permission resolver
Tenant migrationregion:tenant-migration / executePermission resolver
Environment promotionAUTHOR on the source tenant, PUBLISH on the target tenant, both for the owner typeAuthoring policy
Test / QA casesAUTHOR (create, edit, run), PUBLISH (publish, deprecate, archive, delete) on test_caseAuthoring policy
Chat flowsAUTHOR / PUBLISH on chat_flow for authoring; starting and replying to a session is not permission-checkedAuthoring policy
ExtensionsINSTALL_PLUGINS on plugin; PUBLISH_PACKAGES on packageAuthoring policy; Studio disables the buttons with the reason "Managing plugins is not permitted for your role"

See Permissions model for how roles map to resources and actions.

Conventions shared by all screens ​

  • Errors from the backend are shown in a banner at the top of the screen. On Logging, Jobs, Environment promotion, Test / QA cases, Chat flows and Data import the banner reads code: message, where the code is the error code returned by the API; the other screens show the message only.
  • List endpoints that return grids are paginated: pageIndex (default 0) and pageSize (default 25, maximum 500).
  • Before any controller runs, every request that carries X-Tenant-Id passes the tenant's API access rules, which can answer 403 api-access-denied, 403 api-ip-not-allowed or 429 api-rate-limit-exceeded. Requests to /api/v1/** also count against the tenant request ceiling described in API rate limits.
  • All timestamps returned by the API are ISO-8601 instants. The screens render them in the browser locale.
  • Audited actions are written to the audit log (see Logging): backups write category configuration with actions backup.started and backup.verified; job operations write category job.
  • The CLI reaches any endpoint in this section through erp api get|post|put|delete <path> using the logged-in session; see CLI operations reference. Screen pages list the specific commands.