Administration and Company Settings Overview
Audience: Company Admin, Group Admin and Super Admin
Choose the administration area
Settings contains configuration for the selected company or group. Administration contains platform operations and is available to the Super Admin. Seeing a menu does not grant every write operation within it; role, company scope, module access and record state are checked together.
| Need | Menu / guide |
|---|---|
| Company information, branding and company periods | Organization Settings |
| Invitations, company memberships, roles and suspension | Users |
| Holding administrators and ownership | Group Management |
| Effective modules and limits | Entitlement Sets, License and Modules |
| External-data connections and push keys | Integrations |
| Company/group AI models | AI Provider |
| Company menus in use | Menu Settings |
| Default KPI criteria | Settings → Success criteria template |
| DMA / Excellence templates | Their configuration pages under Settings |
| Personal language, password and roles | Profile |
The Strategy Manager can manage business modules, users up to their own level, organization structure and the success criteria template. Company profile editing, API keys, integration endpoint management, AI providers and Menu Settings are company administration areas. See Roles & Permissions.
Super Admin area
Administration contains companies and groups; RBAC, global libraries, sector/country lists, assessment templates, platform success criteria, AI administration and Platform Settings.
In SaaS, entitlements are managed through Presets, Entitlement Sets, and Modules & Catalog. A preset fills the form; changing one does not automatically change existing sets. Prices and limits come from the current catalog. SaaS license administration issues signed licenses for on-prem customers.
In an on-prem installation, the signed license is the entitlement source; set editing and license issuing are unavailable. The catalog and presets are read-only views of the bundled file. The License page explains installation status and modules.
Default Success Criteria
Admin → Default Success Criteria (/admin/success-criteria-default) defines the platform default KPI success criteria: basis, 5 levels (color and two labels, TR and EN) and 4 increasing thresholds. Only Super Admin sees and edits it; other roles cannot open the page.
- Every newly created company (sign-up, a company added by a Group Admin, a tenant created by Super Admin) gets a copy of the template as it is at that moment, as its own success criteria template. The copy has one language: English labels when the language is English, otherwise Turkish labels. On sign-up the language is the interface language used during sign-up; on the other paths it is the language preference of the user who creates the company.
- Changing this template does not change existing companies' templates or KPIs; only companies created afterwards get the new version.
- If it was never saved, the page shows the built-in default (achievement rate, thresholds 60/80/100/110, Very Poor / Poor / Fair / Good / Excellent; TR: Çok Kötü / Kötü / Orta / İyi / Çok İyi). Revert to built-in default fills the editor with these values without saving.
- If someone else saved while you were editing, your save is rejected and you are asked to load the current version. Every save is kept as a revision.
RBAC Management
Administration → RBAC Management is available only to the Super Admin.
- Global permission rows are read-only and show their source. Global role-policy changes arrive with a product version.
- Company overrides customize a role's API or menu permission row for one company. They replace that company's global row; they do not create a new role or module entitlement.
- An API override's key must exist in the global rows. Company overrides cannot target the Super Admin role or GLOBAL scope.
- Changes are audited; propagation to other process instances can take the cache lifetime.
Module entitlement, company-menu availability and authority over a record are separate checks. Investigate the effective module first, then the menu, then role/unit/ownership scope.
Daily review
Inspect invitations and memberships in Users, and KPI changes in the KPI's History tab. Inspect entitlement history in the relevant group set. History and Audit Records distinguishes the record types.
Use Approval Workflows for OKR submissions and decisions. VRIO records do not have a separate submit/approve workflow.
RBAC Management
Administration → RBAC Management is available only to the Super Admin.
- Global permission rows are read-only and show their source. Global role-policy changes arrive with a product version.
- Company overrides customize a role's API or menu permission row for one company. They replace that company's global row; they do not create a new role or module entitlement.
- An API override's key must exist in the global rows. Company overrides cannot target the Super Admin role or GLOBAL scope.
- Changes are audited; propagation to other process instances can take the cache lifetime.
Module entitlement, company-menu availability and authority over a record are separate checks. Investigate the effective module first, then the menu, then role/unit/ownership scope.
Daily review
Inspect invitations and memberships in Users, and KPI changes in the KPI's History tab. Inspect entitlement history in the relevant group set. History and Audit Records distinguishes the record types.
Use Approval Workflows for OKR submissions and decisions. VRIO records do not have a separate submit/approve workflow.
RBAC Management
Administration → RBAC Management is available only to the Super Admin.
- Global permission rows are read-only and show their source. Global role-policy changes arrive with a product version.
- Company overrides customize a role's API or menu permission row for one company. They replace that company's global row; they do not create a new role or module entitlement.
- An API override's key must exist in the global rows. Company overrides cannot target the Super Admin role or GLOBAL scope.
- Changes are audited; propagation to other process instances can take the cache lifetime.
Module entitlement, company-menu availability and authority over a record are separate checks. Investigate the effective module first, then the menu, then role/unit/ownership scope.
Daily review
Inspect invitations and memberships in Users, and KPI changes in the KPI's History tab. Inspect entitlement history in the relevant group set. History and Audit Records distinguishes the record types.
Use Approval Workflows for OKR submissions and decisions. VRIO records do not have a separate submit/approve workflow.