> This page is for Platform Management. > For clean Markdown of any page, append .md to the page URL. > For a complete documentation index, see https://docs.moveworks.com/llms.txt. > For AI client integration (Claude Code, Cursor, etc.), connect to the MCP server at https://docs.moveworks.com/_mcp/server. # Platform Management Overview Platform Management covers the tenant-level settings everything else depends on: the user directory Moveworks builds from your identity and business systems, the roles that decide who can administer and build, the launch rules and folders that decide who can use what, the SSO that gets administrators into MyMoveworks, and the security controls and data-handling specifications your security team will ask about. Most of this is configured once during implementation, in Moveworks Setup and MyMoveworks. It stays relevant after go-live: user ingestion keeps running on a schedule, roles change as teams change, and every plugin that goes to production needs a launch audience. This page is the map. Each section below links to the page that does the work. ## Start With #### [Accessing Moveworks Setup](/platform-management/moveworks-setup/accessing-moveworks-setup) Moveworks Setup is the admin interface for configuring the AI Assistant. It requires SSO to be in place and a Moveworks Setup Admin or Moveworks Setup User role. #### [Roles and Permissions](/platform-management/access-control/manage-roles-and-permissions-for-moveworks-applications) Grant people Admin, Super Admin, or User access to Moveworks Setup, Tool Studio, Analytics, Knowledge Studio, and the other MyMoveworks applications. #### [Ingest Users](/platform-management/user-identity/ingest-users) Connect a primary identity source and the secondary systems whose user IDs Moveworks needs in order to act on an employee's behalf. ## Ingest Users and Configure Identity Moveworks builds one user profile per employee by importing users from a primary source (usually an identity system such as Okta or Microsoft Active Directory) and from secondary sources such as your ITSM, then joining the records on a merging attribute such as email. Built-in plugins such as Ticketing and Access Groups need the user's IDs in those secondary systems, which is why secondary sources matter. The import runs every 4 hours. [User Identity](/platform-management/user-identity) explains how the fetch, map, process, merge, validate, and load steps build the Moveworks user object, and how duplicate users are handled. [Ingest Users](/platform-management/user-identity/ingest-users) is the configuration itself, found under User Identity → Import Users in the Core Platform module. The older [Configure User Identity](/platform-management/user-identity/mw-setup-identity) journey, with its user ingestion processors and filters guides, is still documented. If a user cannot reach the assistant, start with the [Identity and Bot Access Issues Troubleshooting Guide](/platform-management/user-identity/identity-bot-access-issues-troubleshooting-guide). ## Assign Roles There are two role systems, and they answer different questions. * **[Application roles in MyMoveworks](/platform-management/access-control/manage-roles-and-permissions-for-moveworks-applications)** decide who can open each licensed application. A user is an Admin, Super Admin, or User per application: Admins grant or revoke access to one app, Super Admins to all of them. The same section covers how to assign roles using RBAC. * **[Tool Studio roles](/platform-management/access-control/roles-and-permissions)** decide what a builder can do with a specific asset or folder once inside Tool Studio: Manager, Developer, Operator, or Viewer, bundled from separate editing and runtime permissions. These per-asset roles are different from workspace roles such as Tool Studio Admin and Tool Studio Developer. > **Controlled availability** > > Tool Studio access control (per-asset roles, folders, and connector access rules) is in Controlled Availability and may not be available in every workspace. ## Control Who Can Launch and Use Plugins Developer access and end-user access are separate layers. A builder's Use permission on an asset lets them run it while building; it does not decide which employees can use the published plugin. Launch rules do that. Common questions about roles, folders, connectors, and drafts are answered in the [Access Control FAQs](/platform-management/access-control/faqs). #### [End-User Access Control](/platform-management/access-control/end-user-access-control) Three strategies for deciding which employees can use a published plugin: the external system's own authentication, access by design in your API, and access control in Moveworks. #### [Launch Permissions](/platform-management/access-control/end-user-access-control/launch-configuration) List Mode for allow or deny lists by email address, Advanced Mode for DSL rules based on roles, departments, or conditions. #### [Folders](/platform-management/folders) Public, Personal, and Custom folders set default access for everything inside them. Item-level grants widen access but never narrow it. #### [Connectors and Access](/platform-management/access-control/connectors-and-access) Connectors are closed by default (creator and admins only), and only an admin can move one into the Public folder. ## Configure SSO [MyMoveworks](/platform-management/administration/my-moveworks-overview), the portal for every Moveworks application, is reached only through SSO. [MyMoveworks SSO](/platform-management/sso) has provider guides for [Okta](/platform-management/sso/configure-okta-sso-app) and [Microsoft Entra](/platform-management/sso/configure-microsoft-entra-azure-ad-sso-app) (OIDC and SAML for each), OneLogin, and Google, plus generic OIDC and SAML setups and SSO troubleshooting. Once the Moveworks app exists in your identity provider, granting someone access takes two steps: add them to the application in your SSO provider, then grant them a role in Roles and Permissions. ## Review Security and Privacy Settings #### [Security and Privacy Settings](/platform-management/security-and-privacy-settings) Org-wide Tool Studio controls for Super Admins: who can edit connectors, who can use built-in connectors, strict log redaction for broadly launched plugins, and how unsecured webhook listeners are handled. Changes take effect immediately. #### [SIEM Logs](/platform-management/siem-logs) JSON audit logs delivered over SFTP, covering API calls, authentication events, permission changes, and config changes. Each day's file is refreshed every 3 hours. #### [Hyperlink & Button Expiry](/platform-management/hyperlink-button-expiry) How long pre-signed app.moveworks.ai links and in-chat buttons stay clickable, and how long URLs are retained. #### [Attachment Handling](/platform-management/attachment-handling) Where attachments uploaded to the assistant are stored, for how long, and how they are encrypted at rest and in transit. #### [Moveworks Subprocessors for Hosting](/platform-management/moveworks-subprocessors) The current list of subprocessors authorized to process customer data, by data center. ## Find a Setup Module Moveworks Setup groups its modules by product area: Enterprise Search, Ticketing Automation, Access Management, Core Platform, Chat Platforms, Organization Details, and Advanced Tools. The module list is the quickest way to find the configuration page for a specific capability. Tenant-level details such as org name, company email domains, onboarding stage, go-live date, and the AI Assistant avatar live under General Information. #### [Moveworks Setup Modules](/platform-management/moveworks-setup/moveworks-setup-modules) Every Setup module, grouped by product area, with a link to its configuration guide. #### [General Information](/platform-management/administration/organization-information) Org name, company email domains, onboarding stage, go-live date, the MyMoveworks custom domain alias, and the AI Assistant avatar. #### [Monitor Alerts](/platform-management/moveworks-setup/moveworks-setup-alerts) Alerts for events in your instance that may affect skill functionality, under Organization Details → Alerts, with a troubleshooting guide. #### [Audit Logs](/platform-management/moveworks-setup/audit-logs-1) Config change logs, permissions change logs, and built-in plugin logs covering external API calls and workflow steps. #### [Troubleshooting Hub](/platform-management/moveworks-setup/troubleshooting-hub) Ticket Viewer, AI Assistant Chat Playback for replaying a conversation and the assistant's reasoning, and Config Change History. Moveworks Setup also holds [Plugin Controls in Moveworks Setup](/platform-management/moveworks-setup/plugin-management), [DSL Fields Defaults](/platform-management/moveworks-setup/dsl-fields-defaults), [Configuration Delete](/platform-management/moveworks-setup/configuration-delete), and [Onboarding Stage](/platform-management/moveworks-setup/onboarding-stage). Monitor Alerts covers [In-Bot Alerts (Opt-In Based)](/platform-management/moveworks-setup/moveworks-setup-alerts/in-bot-alerts-in-limited-preview) and the [Alerts Troubleshooting Guide](/platform-management/moveworks-setup/moveworks-setup-alerts/alerts-troubleshooting-guide). The Troubleshooting Hub holds [AI Assistant Chat Playback](/platform-management/moveworks-setup/troubleshooting-hub/ai-assistant-chat-playback) and [Configuration Change History](/platform-management/moveworks-setup/troubleshooting-hub/config-change-history). ## Where This Fits Two other areas depend on what you configure here. [Tools](/tool-studio/overview) is where builders create plugins, connectors, and agents; the application roles, folders, and connector rules on this side decide who can do that and with which systems. [Assistant Platform](/ai-assistant) is what employees use in chat and on the web; the user ingestion and launch rules on this side decide who those employees are and which plugins they can reach.