Back to Build
Journey 01

Create an app people can use

Start with one user outcome, select the lightest-fit app experience, and finish with a testable end-to-end slice rather than an empty shell.

  1. Frame the first useful outcome

    Name the user, the decision or task they must complete, the record they need, and the evidence that the task worked. Keep the first increment narrow enough to demonstrate in one sitting.

    Working output: a one-sentence outcome and a three-to-five-step happy path.
    Choose the app experience

  2. Choose the experience that fits the task

    Use the user and task constraints to choose a subtype. Do not combine experiences until one can deliver the first outcome.

    Canvas appUse for tailored task flows, responsive layouts, and multiple connected data sources.
    Model-driven appUse for role-based work centered on Dataverse records, forms, views, and processes.
    Code appUse when a React experience, source-controlled code, or custom interaction is essential.
    Generative pageUse for a focused custom page inside a model-driven app, backed by Dataverse.
    Working output: one selected subtype with a short reason and known constraints.
    Build the vertical slice

  3. Build one end-to-end slice

    Create the minimum navigation, data read or write, validation, and error state needed for the happy path. Use a solution and environment-safe configuration from the start.

    Skills Advisor opens the current catalog so you can select the published Canvas, model-driven, code app, generative page, or Dataverse skill that matches your subtype.

    Working output: a runnable increment that completes the chosen task with representative data.
    Find the matching build skill

  4. Verify with a real task

    Ask a representative user to complete the happy path and one recovery path. Capture gaps in usability, access, data correctness, and error handling before broadening scope.

    Working output: a demonstrated slice, recorded findings, and a prioritized next increment.
    Take the increment to Review
Journey 02

Automate a repeatable process

Define the event, expected result, and exception owner first. Then choose cloud or desktop automation and prove that failures are visible and recoverable.

  1. Bound the process

    Write down the trigger, required inputs, business result, systems touched, completion target, and the person accountable when the run cannot finish.

    Working output: a trigger-to-result process outline with an exception owner.
    Choose the automation type

  2. Select cloud or desktop

    Choose based on where the work happens, not familiarity with the tool.

    Cloud flowUse for service events, schedules, approvals, connectors, APIs, and unattended orchestration.
    Desktop flowUse when the required system exposes only a desktop interface; document machine, session, credential, and unattended-run needs.
    Working output: the selected automation type and a list of dependencies.
    Implement one successful run

  3. Implement the smallest complete run

    Build the trigger, essential actions, and result record. Use clear names, connection references, least-privilege identities, and idempotent behavior where retries are possible.

    Skills Advisor opens current automation options. The catalog includes build-flow for cloud flows; use its search to check current desktop-flow guidance.

    Working output: a successful test run using controlled input and traceable output.
    Find an automation skill

  4. Make failure actionable

    Test invalid input, unavailable dependencies, duplicate events, timeout, and partial completion. Add scoped handling, useful run details, notification, and a documented retry or recovery path.

    Working output: a flow with tested success and failure paths plus owner-facing recovery notes.
    Review reliability and maintainability
Journey 03

Extend an experience where work happens

Add one capability to an existing journey, choose the right surface only after the boundary is clear, and connect the extension through intentional data and action contracts.

  1. Define the capability gap

    Describe what users cannot do today, where they are when the need occurs, and what the existing experience should continue to own. Name the success signal for the extension.

    Working output: a bounded capability statement and the host experience it extends.
    Choose the extension surface

  2. Select the extension surface

    Choose the smallest surface that closes the capability gap.

    AgentUse for conversational discovery or action when knowledge grounding, permissions, fallback, and evaluation can be explicit.
    Mobile appUse for purpose-built mobile tasks that need device-aware interaction and connected services.
    Mobile extensionUse when an existing wrapped Canvas app needs a specific native Android or iOS capability.
    Connected experienceUse a connector, API, Dataverse, or data integration when the visible experience is sufficient but lacks trusted data or actions.
    Working output: one surface choice, its host boundary, and explicit non-goals.
    Define data and action contracts

  3. Connect only what the capability needs

    Define input and output shapes, identity, permissions, latency, error behavior, and ownership. For Dataverse, model the required tables and relationships; for external systems, use supported connectors or typed API contracts.

    Skills Advisor opens current mobile, extension, connector, Dataverse, and integration skills so you can review prerequisites before execution.

    Working output: an implemented happy path with least-privilege access and observable failures.
    Find the matching extension skill

  4. Test the boundary, not only the demo

    Verify authorization, unavailable data, unsupported requests, fallback, and the handoff back to the host experience. For agents, evaluate grounded and ungrounded prompts; for mobile, test the target device conditions.

    Working output: a tested extension with acceptance evidence and a known fallback.
    Review the integrated experience
Journey 04

Ship a change safely

Turn a working increment into a versioned release with environment-safe configuration, independent evidence, controlled promotion, and a practical recovery plan.

  1. Define the release unit

    Inventory changed components, dependencies, data changes, configuration, owners, and acceptance criteria. Separate unrelated work so the release remains reviewable and reversible.

    Working output: a release manifest with a version, owner, dependencies, and acceptance criteria.
    Package for environments

  2. Package and configure the solution

    Place components in the intended solution, verify the publisher and dependencies, and move environment-specific values into environment variables and connection references. Commit unpacked source when that is part of the team standard.

    Working output: a versioned deployment artifact with no hard-coded target configuration.
    Use the packaging guide

  3. Validate in the target path

    Import into a non-production environment, resolve solution-check findings, run functional and access tests, and capture approval evidence. Define rollback criteria before promotion.

    Working output: a validated artifact, approval record, post-deployment checks, and rollback criteria.
    Run the Review journey

  4. Promote, verify, and hand over

    Use the agreed pipeline and approvals to promote the same artifact. Apply target configuration, run smoke checks, monitor the release, and record the operating owner and recovery steps.

    Microsoft Learn opens the ALM overview used by Self-Service Portal's existing release checklist; review it before establishing or changing the delivery path.

    Working output: a verified release with traceable deployment evidence and an owned runbook.
    Open Power Platform ALM guidance