Local and Cloud Accounts

What you will be able to do

• Explain the five core support decisions involved in local and cloud accounts.
• Choose a safe inspection or support method that matches a stated user need.
• Interpret the result as evidence before deciding whether to change system state.
• Apply an identify, inspect, act, verify, document, and recover workflow to a realistic support case.

01

Build the Support Map

Distinguish local and cloud identities, profiles, recovery paths, and sign-in context before changing an account.

Reliable support begins by separating the user's visible symptom from the system layers that could produce it. Record the affected user, exact device or service, timing, scope, expected behavior, observed behavior, and any recent change before proposing a cause.

Use read-only evidence first. Preserve the starting state, ask one focused question at a time, and compare an affected example with a known-good example whenever that comparison is safe and relevant. This creates a baseline another technician can review.

02

Local account

A local account is created and authenticated on one Windows device rather than by a cloud identity provider. In this lesson, it answers one specific support question. Record its evidence separately from the other layers instead of folding everything into a general guess.

Confirm the device name, local user name, and available administrator recovery path before changing access. Start with this approved method: Open Accounts settings and record the account type. Keep the target, time, user context, and visible result together so the reasoning remains reproducible.

The safety boundary is specific: A local password change does not change a cloud password. The expected result is also specific: The account is tied to the correct local device. If the observation does not match that result, preserve it and return to diagnosis instead of adding unrelated changes.

03

Cloud account

A cloud account authenticates with an online identity service and may connect settings, services, or organizational access. In this lesson, it answers one specific support question. Record its evidence separately from the other layers instead of folding everything into a general guess.

Identify the exact provider and sign-in name before initiating password or recovery work. Start with this approved method: Review account information without exposing credentials. Keep the target, time, user context, and visible result together so the reasoning remains reproducible.

The safety boundary is specific: Similar display names can belong to different identities. The expected result is also specific: The cloud identity and its provider are explicit. If the observation does not match that result, preserve it and return to diagnosis instead of adding unrelated changes.

04

User profile

A Windows user profile stores per-user files and settings but is not the same object as the account identity. In this lesson, it answers one specific support question. Record its evidence separately from the other layers instead of folding everything into a general guess.

Determine whether the account can authenticate and whether its profile loads correctly as separate tests. Start with this approved method: Test sign-in and inspect the profile path separately. Keep the target, time, user context, and visible result together so the reasoning remains reproducible.

The safety boundary is specific: Deleting a profile can remove local user data. The expected result is also specific: Identity failure and profile failure are distinguished. If the observation does not match that result, preserve it and return to diagnosis instead of adding unrelated changes.

05

Account recovery

Account recovery proves control through approved methods before credentials or access are restored. In this lesson, it answers one specific support question. Record its evidence separately from the other layers instead of folding everything into a general guess.

Use the provider or organization recovery workflow and verify the requester without asking for a password. Start with this approved method: Start the approved account recovery workflow. Keep the target, time, user context, and visible result together so the reasoning remains reproducible.

The safety boundary is specific: Support staff should never collect a user's password. The expected result is also specific: Recovery follows the authoritative identity process. If the observation does not match that result, preserve it and return to diagnosis instead of adding unrelated changes.

06

Sign-in context

A sign-in name can refer to a local device, personal cloud tenant, or organizational directory context. In this lesson, it answers one specific support question. Record its evidence separately from the other layers instead of folding everything into a general guess.

Record the context shown at sign-in and test the same identity against the intended resource. Start with this approved method: Confirm device, tenant, and user principal before changes. Keep the target, time, user context, and visible result together so the reasoning remains reproducible.

The safety boundary is specific: Changing context can create a different user profile. The expected result is also specific: The identity is evaluated in the correct directory context. If the observation does not match that result, preserve it and return to diagnosis instead of adding unrelated changes.

07

Apply One Controlled Support Action

Before changing state, name the exact target, required authorization, expected result, user impact, and recovery or reversal path. Protect unsaved work and relevant data, then explain any interruption or privacy exposure to the user in plain language.

Make one narrow change and stop. If a prompt, error, identity, device, path, or result differs from the approved plan, do not improvise with broader access or several fixes. Capture the new evidence and reassess the system layer that produced it.

A successful button, command, or progress message only confirms that an operation ran. Repeat the original user workflow and compare it with the baseline to decide whether the support objective was actually met without a new side effect.

08

Verify, Document, and Handoff

Verification should test the original success condition and one safe boundary condition. Record what changed, what remained unchanged, who confirmed the result, and which temporary permissions, sessions, files, or tools were removed after the work.

Write the support record so another person can continue without repeating completed steps. Include exact evidence and outcomes, but remove passwords, tokens, private content, and any personal information that the support purpose does not require.

Escalate when the required authority, product support, safety procedure, privacy permission, recovery evidence, or diagnostic certainty is missing. A complete escalation packages the symptom, scope, evidence, actions, results, risk, and next decision rather than forwarding an empty ticket.

09

Recap Before Practice and Prove

Start with local account. Confirm the device name, local user name, and available administrator recovery path before changing access. The result to preserve is the account is tied to the correct local device.

Keep cloud account separate. Identify the exact provider and sign-in name before initiating password or recovery work. Respect this boundary: similar display names can belong to different identities.

Use user profile to narrow the case. Determine whether the account can authenticate and whether its profile loads correctly as separate tests. Verify that identity failure and profile failure are distinguished.

Before a broader action, review account recovery. Use the provider or organization recovery workflow and verify the requester without asking for a password. Stop if support staff should never collect a user's password.

Finish with sign-in context. Record the context shown at sign-in and test the same identity against the intended resource. Record the final evidence, user outcome, and any remaining escalation or recovery boundary.