Customer-facing product guide
Complete proven source-to-decision tasks
Use these task-oriented paths to move supported material into reviewed candidates, preview schedule impact, inspect failed-test traceability or capture the workflow directly.
1. Start with the decision context
Purpose
An integration project represents one governed project context. The portfolio view summarizes multiple accessible integration projects; project dashboards show the selected project.
Connected records
Project profile, partners, integrations, milestones and permission-visible project signals.
What you get
A guided setup path, a configurable project dashboard and a clear switch between portfolio and project context.
Typical workflow
- Create or select the integration project that owns the project context.
- Use the Setup Guide to identify missing minimum evidence.
- Configure the dashboard from the curated widget catalog for the project audience.
2. Build the integration and partner context
Purpose
Partners group the business context; integrations and specifications describe the technical exchange or a custom non-structured integration scope.
Connected records
Partners, integrations, JSON/XML/YAML/CSV or custom specifications, approvals, documents and assigned provider scopes.
What you get
One place to see the integration contract, its partner context, review state and relevant external evidence.
Typical workflow
- Create the partner and define the integration direction and type.
- Add a structured or custom specification and maintain its versioned content.
- Use Document uploads for source intake and version history. Document Intelligence opens an exact eligible version and starts extraction only after your explicit confirmation — opening it never starts extraction automatically.
- Optionally assign selected Jira, Confluence or SharePoint scopes to the partner and link relevant source items.
3. Connect change intent to quality evidence
Purpose
Changes and use cases describe what should change; test cases, cycles, executions and defects show how it was verified.
Connected records
Changes, use cases, specifications, test cases, test cycles, execution results, deviations and defects.
What you get
Traceable coverage and visible gaps between intent, implementation context and verification.
Typical workflow
- Capture the change and its use cases in the relevant integration project context.
- Link or create the required test evidence and execute it in test cycles.
- Record defects and retests so unresolved quality evidence stays visible.
4. Plan milestones and assess readiness
Purpose
The planning model connects activities, dependencies, milestones, calendars and capacity with current project-health evidence.
Connected records
Activities, dependency types, working calendars, duration/capacity profiles, milestones, risks, checklists and approvals.
What you get
Deterministic schedules, baseline comparisons, plan-versus-actual trends and scenario impact previews.
Typical workflow
- Import or create planning activities and confirm their mapping before adoption.
- Maintain dependencies, calendars and duration or capacity profiles.
- Use baselines and scenario previews to inspect impact without silently changing the approved plan.
5. Carry evidence through release and rollback
Purpose
Release readiness joins quality, risk and approval evidence with deployment and rollback execution records.
Connected records
Releases, environments, deployment plans and executions, approvals, release defects, rollback plans and executions.
What you get
A reviewable release decision basis and an auditable operational trail.
Typical workflow
- Prepare the release and inspect its readiness blockers.
- Record the authorized deployment plan and execution result.
- Maintain rollback preparation and execution evidence when required.
6. Link selected external evidence
Purpose
Customer-authorized Microsoft and Atlassian connections can expose bounded source catalogs for partner-scoped evidence.
Connected records
Selected Atlassian site and project/space scopes, SharePoint site/drive/folder scopes, external references and content snapshots.
What you get
Relevant source evidence in traceability and the knowledge graph without treating every accessible provider item as project context.
Typical workflow
- Connect the provider to the intended integration project and select the canonical site where required.
- Assign the relevant project, space, site, drive or folder scope to a partner.
- Search and link an item only after selecting the intended target record and relationship.
7. Create reports, presentations and governed exports
Purpose
The Report Center brings generated Project, Technical Specification, Go-live/Handover and Test outputs together with reporting snapshots and exports. Reporting projects the same permission-filtered point-in-time state across audiences and formats.
Connected records
Management, selected Partner and Team views, readiness assessments, decision evidence, provenance, limitations, as-of timestamps, versions and fingerprints.
What you get
Browser-native presentations, Management Status, readiness reports, decision briefs, print/PDF, versioned JSON and bounded unsigned audit export packages.
Typical workflow
- Open Report Center and choose a generated output, audience or report scope; Document uploads remains the source-intake and version-history area.
- Save an immutable snapshot when a reproducible point-in-time version is required.
- Present it in the browser or export the same governed projection; current permissions are checked again when stored output is opened or downloaded.
8. Use governed AI only where it adds evidence
Purpose
AI features are task-specific, optional and built around bounded snapshots rather than a free autonomous agent.
Connected records
Integration project AI settings, allowlisted task context, evidence references, exchange logs, insights, review drafts and reversible policies.
What you get
Product guidance and planning/risk observations that can be reviewed, traced and deliberately adopted.
Typical workflow
- An authorized administrator explicitly enables the integration project, provider mode and permitted AI tasks.
- The service builds and previews a bounded, permission-visible snapshot for the selected task.
- Users review proposals; controlled draft automation requires an additional explicit policy and remains reversible.
9. Apply access, provenance and trust boundaries
Purpose
Server-side permissions determine access. Provenance and decision states explain how visible information was created and reviewed.
Connected records
Project roles, groups, critical permissions, activity categories, provenance kinds, decision states and technical trust claims.
What you get
Permission-aware navigation, bounded audit evidence and a customer-visible distinction between rules, sources, AI and human confirmation.
Typical workflow
- Start from system-role templates and assign project roles or groups deliberately.
- Review effective permissions before granting critical management capabilities.
- Use Trust & Data Processing for the technical hosting, provider and human-control boundaries.
How to read product signals
- Source-derived
- Evidence retained from a connected or imported source.
- Deterministic
- A repeatable rule or formula, without an AI provider call.
- Knowledge-model derived
- A relation or signal derived from the canonical graph model.
- AI-supported
- A bounded provider-assisted observation or proposal.
- Human-confirmed
- A result explicitly accepted by an authorized user.