Back to Design

Launch a new solution

Turn your idea into a clear design, from the first business question to a build-ready blueprint.

Before you start

Bring your intended outcome, user groups, existing systems, sensitive-data requirements, timeline, and measures of success to the design session.

Supporting published skills

Suggested sequence

  1. Plan the solution boundary

    Identify the work to improve and the systems that must remain. Record the scope, assumptions, and constraints in a short solution brief.

  2. Model the experience and data

    Match user tasks to an app experience. Define core entities, relationships, and ownership before selecting components. Keep a model and a record of the alternatives considered.

  3. Validate access and design risks

    Map roles to data and actions, then review the proposed architecture. Leave with an access matrix and a prioritized list of risks to resolve before delivery.

Modernize an existing app

Keep what works. Rethink what doesn't. Find a lower-risk path from today's app to your next design.

Before you start

Bring the current architecture, user pain points, performance evidence, dependencies, data volumes, release process, and support commitments to the design session.

Supporting published skills

Choose a Migration Factory track

Complete the basic Self-Service Portal framing above first, then choose the track that matches the legacy source. Bring a sanitized source artifact and current dependencies; each track produces a target plan or implementation assets plus migration risks to validate.

Suggested sequence

  1. Assess the current system

    Separate design limitations from implementation issues. Record a baseline and the constraints a replacement or incremental change must satisfy.

  2. Compare target experiences and integration patterns

    Compare retaining, extending, or replacing the current experience. Document data ownership, latency, failure handling, and coexistence requirements alongside the chosen architecture.

  3. Plan a reversible transition

    Define solution boundaries, test environments, migration checks, rollout stages, and rollback criteria. Agree on ownership before changing the production system.

Design for enterprise scale

Give more teams room to build through Managed Environments, centrally governed groups, intentional maker routing, secure access, and repeatable delivery.

Before you start

Bring details about tenant and compliance constraints, delivery teams, data classifications, the environment inventory, the support model, and release responsibilities to the design session.

Supporting published skills

Suggested sequence

  1. Baseline the estate and reduce default-environment dependence

    Inventory environments, makers, apps, flows, connectors, owners, and business criticality. Define the narrow role of the default environment, apply appropriate controls, and plan to migrate, quarantine, or retire assets that need stronger lifecycle management. Do not treat the default environment as the production target for departmental solutions.

  2. Group Managed Environments and publish inherited rules

    Organize managed environments by business unit, project, region, purpose, or risk. Define security, sharing, data retention, AI, and ALM rules at the group level. Published rules apply to every member environment and cannot be overridden locally; place legitimate exceptions in a separately governed group instead of weakening the standard.

  3. Route makers, promote solutions, and operate the model

    Use environment routing for eligible maker populations so they land in managed personal developer environments instead of the shared default environment. Define group assignment, licensing checks, support, monitoring, pipeline stages, approvals, and promotion into test and production. Record how ownership changes and exceptions are reviewed.

Validate a proposed design

Find the gaps before you commit. Turn design risks into clear decisions and next actions.

Before you start

Bring the proposed architecture, key decisions, user journeys, security model, service expectations, known risks, and any prototype or test evidence to the review.

Supporting published skills

Suggested sequence

  1. Assess the design across quality areas

    Review reliability, security, operational excellence, performance efficiency, and experience optimization. Record gaps and their business impact.

  2. Resolve the material design risks

    Route findings to the relevant architecture, data, or access decision. Capture alternatives, tradeoffs, and acceptance criteria rather than treating a checklist as approval.

  3. Agree on evidence and next actions

    Assign an owner to each remaining risk and define what must be demonstrated before release. When an implementation exists, use the Review pillar's tools or request a deeper review.

Find supporting skills

Power CAT skill links open marketplace details and prerequisites, not a running skill. Other published skills route through Skills Advisor. Review requirements before installation or execution in a compatible host, particularly when a skill can change an environment.

The Design guides above are portal-authored planning outlines, not one-to-one names of published skills. Use the current catalog to find skills that support the decisions in your chosen sequence.