> ## Documentation Index > Fetch the complete documentation index at: https://docs.aptlydone.com/llms.txt > Use this file to discover all available pages before exploring further. # System Settings Overview > Configure Aptly's tenant-wide behaviors, module options, and workflow logic — across Account Settings, Users & Roles, Groups, Notifications, Advanced, Integrations, and Subscription. ## Overview The **Settings** area lets administrators configure tenant-wide defaults, enable or disable module features, manage organizational structure and access, and govern integrations and billing. Most settings apply across the tenant unless noted; a smaller set defines defaults for new users that can later be adjusted at the user level. Settings are organized into two groups in the left navigation: * **Account Settings** — a parent menu containing tenant configuration for individual modules (Info & Region, Group Types, Positions, Decisions, Delegations, Matrices, Documents, Actions). * **Standalone Settings** — Users & Roles, Groups, Notifications, Advanced, Integrations, and Subscription, each accessed directly from the Settings menu. This page covers each area in the order it appears in the Settings menu. *** ## ⚙️ Info & Region Set foundational tenant defaults that cascade across the platform (users can override some in their profile): * **Default Time Zone** (e.g., EST – `America/New_York`) * **Date Format** (default: `MM/DD/YYYY`) * **Base Currency** (e.g., USD) * **Multi-Currency Support** If enabled, values can display in a user's preferred currency using admin-maintained conversion rates. > **Notes** > > * Changing **Base Currency** is restricted after currency-based authority limits exist. > * Conversion rates can be uploaded or edited in bulk. *** ## 🧑‍🤝‍🧑 Group Types Control which hierarchical group types are available across the tenant: * **Organizations** — *always enabled*; cannot be disabled * **Departments** — toggle * **Locations** — toggle * **Custom Group Types** — optional (e.g., Projects, Teams, Cost Centers) **Behavior & validations** * Disabling a group type hides it from create/edit forms and filters. Existing associations remain available in version history. * When disabling, you may choose to **Keep Associations** (hide going forward) or **Remove Associations** (break links going forward). * Some features depend on specific group types; for example, the **Functional** pathway requires **Departments** to be enabled. > Group Types defines *which* dimensions are available. The actual organizations, locations, departments, and custom-type values are managed under **Groups** (see below). *** ## 🪪 Positions **Positions** represent job titles or authority-holding roles in your organization (e.g., "Head of Legal", "Controller", "Plant Manager"). Positions are used across Aptly to assign authority to **people in a position** and can also represent governing bodies (e.g., a Board or Committee) even if no specific user is assigned. From the Positions page, admins can: * Create and manage positions * Associate positions with organizational scope (Organizations, Locations, Departments) * **Deactivate** or **reactivate** positions (recommended over deletion for most changes) * **Delete** positions when appropriate * **Bulk upload** positions using a template * View positions synced via Directory Sync (SCIM) or HRIS integrations (synced fields are read-only) > Deactivating a position can affect existing delegations issued to that position. With **Auto-Revoke** enabled, those delegations may be revoked automatically; with Auto-Revoke disabled, they may be flagged Invalid for review. *** ## 🧾 Decisions Define how authority is expressed and governed on Decisions and Delegations. ### Authority Value Types Choose which limit types can be used: * **Currency** (on by default) * **Number** * **Time** — days/months/years (on by default) * **Authorized** — Yes/No-style flags such as "Authorized to sign" (on by default) * **Percentage** > Disabling a value type hides it on new records; historical values remain visible in history. ### Conditions (toggle) Enable **Conditions** to add policy constraints to Decisions and Delegations (e.g., "Two bids required for spend > \$200k"). If turned off, conditions are hidden everywhere but not deleted. ### Roles (toggle) Enable **Roles** (e.g., Consulted, Informed, Co-Signer) on Decisions and Delegations to capture engagement requirements alongside authority. If turned off, role assignment is not available on Decisions or Delegations. *** ## 👥 Delegations Control delegation types, recipient behavior, issuance rules, redelegation limits, and module-level features. ### Authority Types * **Approval** (on by default) * **Signatory** (on by default) * Admins can add **custom authority types** as needed (e.g., Responsible, Pre-Approval, Competitive Quote) ### Recipient Types * **Personnel in Position** (*enabled*) Delegate authority to one or more specific people **while they hold a specific position**. Supports **Auto-Issue** and **Auto-Revoke** to govern what happens when a user is added to or removed from that position. * **Position Only** (*enabled*) Delegate to a **position** with **no specific person** designated. Authority persists with the position regardless of who currently holds it. * **Specific Personnel** (*optional*) Delegate directly to **named individuals**, regardless of position. If a user's position changes later, the delegation is unaffected. ### Issuance Controls * **Auto-Issue** (applies to *Personnel in Position* only) When enabled on a delegation, authority automatically issues to any user who **currently holds — or later assumes** the specified position, as long as the delegation remains active. Pathway restrictions (Functional, Direct-Line) are respected; users who don't meet the pathway criteria are skipped. * **Auto-Revoke** (applies to *Personnel in Position* only) Automatically revokes issued authority when a user **no longer** holds the assigned position. * Single-recipient delegations are revoked entirely. * Multi-recipient delegations remove only the affected user. * Child redelegations issued by that user may be flagged Invalid according to pathway and issuer rules. ### Global Redelegation Limits Define the **maximum percent** of a source authority that may be redelegated by recipients: * **Currency / Number / Time / Percentage** — default **100%** * **Authorized** — default **allowed** > Users with the **Global Redelegation Limit Override** permission can redelegate up to the source authority (subject to Decision limits), even when global limits are lower. ### Module Settings Module Settings under Delegations control which delegation-related features are available in the Delegations module: * **Documents on Delegations** — when enabled, users can attach documents to individual delegations. (Decision-level documents always cascade to downstream delegations; delegation-level documents do not cascade further.) * **Delegation Pathway** — when enabled, delegations display a **Pathway** tab with an org-chart-style visualization of how authority flows from issuer to delegate. Each node shows the delegate's name/position and authority limits; badges indicate non-active or invalid states (Pending, Suspended, Revoked, Expired, Archived, Invalid), and nodes link to the underlying records. *** ## 🧩 Actions Enable automated workflow tracking through **Actions**. Each setting, when enabled, generates system actions with audit history. ### Delegation Requests Allow authorized users to **request authority** within a Decision or an existing Delegation. * **From a Delegation**: requests can be directed to the **Issuer**, **Recipient**, or **both**. * **From a Decision**: requests route to the **Decision Owner/Creator**. * Each request creates an **Action** for review and resolution. * If disabled, the request option is hidden even for users with request permissions. ### Delegation Acceptance Require recipients to **explicitly accept** (or reject) issued delegations before they are acknowledged. * When enabled, an **Acceptance Action** is assigned to each recipient and the acceptance date is recorded on the delegation. * If disabled, issued delegations are acknowledged automatically. ### Decision Role Acknowledgement Notify users assigned a Role (e.g., **Consulted**, **Informed**) and prompt them to **acknowledge** the assignment via an Action. * If disabled, role assignments do not generate actions or notifications. ### Delegation Approvals Require approval by designated approvers before a delegation becomes operational, and optionally re-approval when an issued delegation is changed. * **Approval at issuance** — When enabled, every newly issued delegation enters **Pending** status and an **Approval Action** is assigned to eligible approvers. On approval, the status changes to **Issued**; on rejection, the delegation returns to Draft or its prior state. * **Change Approval** — When enabled, substantive edits to an already-Issued delegation also route for approval. The delegation remains Issued with a **Pending Re-approval** indicator while under review; on approval, the changes are committed to the live record. > See [Delegation Approvals & Logic](/essentials/delegation-approvals) for full detail on when approvals are required, how approvers are assigned, the change-approval flow, and how the audit trail is captured. ### Action Templates Create reusable **templates** for common actions to standardize descriptions, requirements, and assignments. ### Action Types Define and manage **categories** for actions (e.g., Task, Review). * Admins can add and edit **custom types**. * System default types cannot be edited or disabled. *** ## 📂 Documents Configure how documents are used and governed across the tenant. ### Management * **Link Documents** — Link **external files** (e.g., on intranet/DMS) to Aptly records. The file remains outside Aptly; the reference lives in Aptly. * **Upload Documents** — Upload and **store files in Aptly** for easy access, governance, and external sharing where allowed. ### Document Types Enable **Document Types** so users can classify documents (defaults include **Policy**, **Procedure**, **Protocol**). Admins can add **custom types** to reflect organizational needs. ### Document Versioning Enable to manage document versions and metadata. * Default fields can be toggled individually (e.g., **Effective Date**, **Code**, **Version Label**). * Admins can add **custom version fields** (e.g., "Regulatory Ref", "Revision Cycle") that appear on all documents when enabled. ### Document Oversight Enable **oversight roles** on documents and optional task generation: * **Owner** — the person who created or maintains the document (always enabled). * **Responsible Authority** — accountable for content accuracy and applicability. * **Approval Authority (Approver)** — must formally approve before finalization/distribution. * **Generate Approval Action**: automatically assigns an approval task when a document is published; subsequent edits to a published document re-trigger approval. * **Reviewer Authority (Reviewer)** — performs initial and periodic reviews for compliance/relevance. * **Generate Review Action**: automatically assigns a review task per configured cadence or when a review is due. > If Document Oversight is disabled, oversight roles/fields are hidden in the UI. If Versioning is disabled, only a single current version is maintained. *** ## 🧮 Matrices Control matrix types and sharing behavior. * **Decision Matrix** — on by default * **Authority Matrix** — on by default > If the Matrices module is enabled, at least **one** matrix type must remain active. **Sharing Options** (disabled by default) * **External Sharing** — allow read-only sharing outside your tenant * **Password Protection** — require a password for external access *** ## 🧑 Users & Roles Located directly under the Settings menu, **Users & Roles** is where admins manage **user records** and the **roles** that govern what users can see and do across Aptly. * **Users** — Add, invite, edit, deactivate, and bulk-upload users; review users synced from HRIS or Directory Sync (SCIM) sources. * **Roles** — Manage **default roles** that ship with every tenant (System Admin, Global Authority Manager, Group Authority Manager, Global User, Group User, Restricted User, Auditor) and create **custom roles** by cloning a default or starting from scratch. Roles control module access, scope (tenant-wide vs. specific Groups), and fine-grained permissions on Decisions, Delegations, Matrices, Documents, Actions, Reporting, and Settings. * **User Configuration** — Configure user attributes, field visibility, and which fields are sync-controlled. > See [Roles & Permissions](/essentials/roles-permissions) for the full permission model, including how default roles, scopes, and record capacities combine to determine effective access. *** ## 🏢 Groups **Groups** is where admins manage the actual organizational dimensions used throughout Aptly to scope authority and access — distinct from **Group Types** (which controls *which* dimensions are available). The tabs visible on this page reflect the Group Types enabled for your tenant: **Organizations** is always present; Locations, Departments, and any custom group types appear if enabled. From this page, admins can: * Create, edit, deactivate, and delete groups within each enabled type * Define parent-child relationships (Organizations can only have other Organizations as parents; other group types can have parents from any enabled type) * Associate groups with users, positions, decisions, and delegations * Manage groups synced from HRIS or SCIM sources > See [Group Management](/essentials/groups) for the full guide to group hierarchies, sync behavior, and best practices. *** ## 🔔 Notifications The **Notifications** settings page lets tenant administrators define the **default notification preferences** that apply to **new users** when they are created. Existing users manage their own notification preferences from their profile. ### Global Notification Generation A tenant-level toggle at the top of the page controls whether Aptly generates **any** notifications (system or email) for the tenant. * **Off** — No notifications are sent for the tenant, regardless of tenant defaults or user-level preferences. Commonly used during onboarding or data migration to suppress premature alerts. * **On** — Notifications follow tenant defaults (for new users) and each user's personal preferences. ### What can be configured Notifications are organized into four tabs — **Delegations**, **Decisions**, **Actions**, **Documents** — each listing the notification types available in that area. For each notification type, admins can configure: * **On / Off** — whether the notification is enabled at all for new users * **System** — in-app delivery (notification tray) * **Email** — email delivery * **User(s)** — which participant(s) should receive the notification (varies by type) * **Trigger** — the event or timing that causes the notification to be sent > Notifications are informational alerts; **Actions** are tasks assigned to users that may require completion. A user can receive both for the same event. *** ## 🔐 Advanced The **Advanced** settings page provides administrative security and API access tools, organized into three tabs: * **User Access Logs** — A security-focused log of user login activity (timestamp, user, remote address, actor type, tenant, and additional details). Filterable by time window. Used by IT, Security, and Admin teams to verify access patterns and investigate suspicious activity. * **User Access Keys** — Self-service creation and management of API keys for the currently logged-in user. Each key inherits the permissions of the user who creates it. * **Access Key Management** — Administrative view for managing access keys across the tenant. Authorized admins can view, activate, deactivate, or delete keys created by other users — useful for offboarding, security response, and governance review. > Access to each tab is controlled by separate role permissions (e.g., User Access Logs and API Key Management can be granted independently). For integrations, the recommended pattern is to create a dedicated **service account user** with a purpose-built role and generate keys from that account rather than tying keys to individual employees. *** ## 🔗 Integrations The **Integrations** area is where admins manage connections between Aptly and external systems — including HRIS/ERP platforms (e.g., Workday, SAP, Oracle), identity providers (SCIM-compliant IdPs such as Microsoft Entra ID, Okta, PingIdentity), and other partner platforms. From here, admins can configure new integrations, monitor active integration runs, review logs, and troubleshoot sync issues. Advanced workflow automation and data transformation may also be available depending on tenant configuration and subscription. > For the current list of supported **Connectors** and partner platforms, see [Enterprise Integrations on the Aptly website](https://www.aptlydone.com/platform/integrations). > See [SSO & SCIM Configuration](/essentials/sso-scim) for Directory Sync setup and field mapping guidance. *** ## 💳 Subscription The **Subscription** page lets authorized administrators view plan details, monitor usage for any usage-based charges, manage add-ons, and access invoices (where in-platform billing is configured for the tenant). Some tenant capabilities (for example, custom group types, multi-currency support, or advanced integration features) may depend on subscription tier. If a feature appears restricted, the Subscription page is the place to confirm what's included on the current plan. *** ## 🔐 Roles & Access (at a glance) * System behavior is enforced by a combination of **role permissions** and **fine-grained checks** (e.g., who is Issuer / Recipient / Owner / Approver / Reviewer / Shared user). * Many settings on this page **toggle UI and workflow availability**; users still require the corresponding **role permissions** to act. * Tenant-level toggles set the boundaries; Group scope and record capacity refine *who* can do *what* within those boundaries. *** ## ✅ Tips & Good Practices * **Start broad, constrain with groups.** Give the minimal tenant-level permissions required, then use Group scopes and FGA capacities to narrow real-world access. * **Use Action Templates** for recurring workflows (approvals calendars, periodic reviews, annual attestations). * **Keep Document Types and Version fields lean** to improve reporting and audit clarity. * **Use Auto-Issue and Auto-Revoke deliberately**, with clear communication to stakeholders — these behaviors automate authority changes when people move into or out of positions. * **Use service accounts for integrations** rather than tying API keys to individual employees, so keys survive staffing changes and integration activity is clearly auditable. * **Suppress notifications during migrations** by toggling Global Notification Generation off; turn it back on once the tenant is ready for users. *** ## 🧭 Related Pages * [Delegation Lifecycle →](/essentials/delegation-lifecycle) * [Delegation Approvals & Logic →](/essentials/delegation-approvals) * [Actions and Workflows →](/essentials/actions-and-workflows) * [Roles & Permissions →](/essentials/roles-permissions) * [Group Management →](/essentials/groups) * [Document Management →](/essentials/document-management) * [Matrix Management →](/essentials/matrix-management) * [SSO & SCIM Configuration →](/essentials/sso-scim) *** System settings apply at the **tenant level**. For user-specific behaviors, see **User Profiles** and **Roles & Permissions**. If you need help mapping settings to your governance model, contact [support@aptlydone.com](mailto:support@aptlydone.com) or visit the Aptly Support Portal.