FAQ

BotPM is an AI-native project, program, and PMO workspace. It brings charters, SOWs, schedules, budget signals, EVM, RAID, stakeholders, governance, reports, and closeout together with controlled AI assistance.

Project managers use it to run delivery. PMO leaders use it for consistency and governance. Sponsors and executives use it for visibility and approvals. Org admins use it for policy, team, integrations, and settings. Super admins use it for platform-level administration.

A chatbot answers prompts. BotPM works inside a project system of record: projects, documents, bots, roles, autonomy, approvals, and audit history. The goal is controlled project execution, not loose conversation.

Assist gives insights, drafts, summaries, and recommendations. Operate runs low-risk actions that policy allows. Lead prepares high-impact proposals and routes them for human decision. Your admin, subscription, feature flags, and PMO policy decide what is available.

Start with Assist for new pilots, sensitive projects, or teams still learning the workflow. Move to Operate only for mature, low-risk workflows. Use Lead when you want the system to prepare strategic recommendations but keep a human approval step.

BotPM is multi-tenant. The organization ID tells the app and APIs which workspace to load. If you see wrong or missing data, confirm you are in the correct organization before assuming data is gone.

Use the organization selector if your deployment shows one, or open a link with the correct organization_id. If you only belong to one organization, BotPM usually redirects you to that default workspace.

Common causes are wrong organization, insufficient role, missing assignment, project archived status, or a tenant policy. Ask an org admin to confirm your organization membership and project access.

Super admin controls platform-level and superadmin-only tools. Admin can access platform operator tools where enabled. Company admin / org owner manages a workspace. PM / project manager works projects and governance. Executive reviews oversight and approvals. Viewer is read-focused.

Super admins can manage platform and broad user access in Operator console → User access. Org admins manage organization-scoped team access in Settings → Team access when allowed. Follow least privilege: give the smallest role that lets someone do their job.

Org admins usually use Settings → Team access for workspace members. Super admins use Operator console → User access to create users, choose platform or org-scoped roles, assign organization scope, and set an initial password if needed.

Deactivate the user instead of deleting history. This preserves audit context while preventing sign-in. For org-only access, use Team access. For platform or cross-role access, use User access as a super admin.

The governance inbox is where proposals, escalations, and high-impact actions wait for a human decision. It turns an AI recommendation into an approved, rejected, or revised decision on record.

Open Governance inbox, review the rationale and affected project details, then approve, reject, or request changes. Check scope, schedule, cost, risks, and stakeholder impact before approving.

Your role may not include approval rights, the item may belong to another organization, the action may require step-up or policy approval, or the workflow may be restricted by autonomy level. Ask your org admin or PMO owner.

Check autonomy level, bot assignment, pending proposals, your role, quota, feature flags, integration health, and organization policy. Many blocks are intentional controls rather than product bugs.

Open Bot assignments, choose the project or work area, select the bot profile if your org has multiple bots, then choose the autonomy level. Start conservative if the workflow is new.

Do not approve it blindly. Check the source project data, documents, assumptions, and date range. Reject or request rework in governance, then fix the underlying project data if the recommendation came from stale or incomplete inputs.

Open Projects, choose create/new if your role allows it, enter the core details, attach charter or SOW documents, then review schedule, budget, stakeholders, risks, and bot assignment.

Upload a supported source document, wait for extraction, review the extracted fields, correct anything that looks wrong, then attach or use the result in the relevant project workflow. Extraction is assistance, not a legal sign-off.

Use Charters & SOW to create, import, or review the scope baseline for project work. Keep assumptions, deliverables, milestones, exclusions, and acceptance criteria current so reports and governance proposals have the right source context.

Open the project hub and use schedule, budget, and EVM views where enabled. Keep dates, cost, and baseline information current before generating reports or approving changes.

Use the project RAID and governance areas to keep risks, issues, actions, dependencies, decisions, and escalations visible. High-impact changes should go through governance instead of being hidden in comments or offline documents.

Use the project stakeholder area to track key people, communication needs, influence, sentiment, and follow-ups. Keep stakeholder data current before status reports or escalation packs are generated.

Open Reports, choose the report type, organization, project or portfolio scope, and date range, then generate. Review output before sharing. If a report looks wrong, fix project data first.

Exports depend on your role, deployment, and enabled features. Reports and project pages may expose downloads. Security/privacy pages may expose data export workflows for authorized admins.

Open the project closeout area, review completion state, documents, decisions, RAID, benefits, lessons learned, handover tasks, and unresolved actions. Archive only after your PMO closeout process is complete.

Confirm the correct organization, project filters, role, and URL organization_id. If you just created a project or uploaded data, refresh after a moment. If the API is down or access is denied, contact support with the error text.

Settings controls your workspace: account, organization, team, billing, usage, notifications, webhooks, integrations, and security/privacy. Admin / Operator console pages are platform-level tools for super admins and platform operators.

Open Settings → Billing and Settings → Usage if billing is enabled. Trial banners and usage limits come from your subscription configuration. If checkout or portal buttons are missing, ask an admin or platform operator to check billing setup.

Some actions may be blocked or limited. Open Usage to review consumption, then reduce activity, upgrade, or ask an admin to adjust limits if your plan allows it.

Open Settings → Notifications to configure channels, categories, severity, summaries, and frequency where enabled. Some critical system or governance notifications may be required by policy.

Webhooks send BotPM events to external systems such as ticketing, collaboration, or reporting tools. Use Settings → Webhooks to configure endpoints, event scope, and secrets if your role allows it.

Open Settings → Integrations, choose a provider, add credentials or OAuth connection, test the connection, then confirm data appears in project or reporting workflows. Never paste secrets into comments or support chat.

See the Trust center and your DPA for tenant isolation, processed data, subprocessors, access controls, and security posture. Use role-based access, least privilege, SSO where enabled, and audit-friendly governance decisions.

SSO depends on your deployment and organization configuration. If SSO is enforced, password login may be blocked for most users. Ask your org admin or platform operator to confirm SSO settings.

Use the self-service password reset flow if enabled. Super admins can reset passwords from Operator console → User access when required. Use admin resets carefully and follow your security policy.

Some deployments require email verification before full access. Check your inbox and spam folder, or ask an admin to resend verification or confirm your account state.

Yes. REST APIs, OpenAPI docs, and webhooks are the usual integration path. Use the in-app Docs hub and API reference for technical details, and coordinate credentials with your platform or org admin.

User guide is for everyone using the product: navigation, first steps, and how things work. Docs includes technical, operator, API, integration, release, and runbook material. Use the guide first; use Docs for depth.

Typically org admins, PMO owners, or authorized project leads can change autonomy. Super admins may manage broader platform settings. If a control is disabled, ask the appropriate admin instead of working around policy.

The feature may be unavailable for your role, subscription tier, organization policy, feature flag, or deployment mode. Ask an admin to confirm whether it should be enabled for your workspace.

Refresh the page or sign out and back in so the session role is reloaded. If the page still looks wrong, ask a super admin to confirm the backend role and organization assignment.

If enabled, support contact details and conversation context may be logged for platform support review. Do not submit secrets or sensitive data unless your support process explicitly allows it.

Include organization, project, user, role, page URL, time, action attempted, expected result, actual result, and any error message. Screenshots help, but avoid sharing secrets.

Refresh first. If role, navigation, or feature state still looks wrong after a role change or deployment, sign out and back in. Browser cache clearing is usually a last resort.

Many dashboard pages are responsive, but complex project, report, and admin workflows are best on a desktop or laptop because tables, forms, and approvals need more space.

Open the Help drawer, FAQ, Docs hub, your internal pilot runbook, or your configured L1/L2 support contact. Tenant-specific access, data, billing, and integration issues should go through your admin or support channel.