Solution management & ALM

Solution work is where good ALM happens… and where “Why is Prod different?” is born. These tools help you build deployable solutions, chase down missing dependencies, and answer what changed without turning into a full-time detective.

Pick your weapon (quick decision guide)

• Need: Add the right components into a solution quickly (especially “oops we forgot that web resource”)
  Tool: Solution Components Mover
  Why: Builds a clean, complete deployment package without manual scavenger hunts

• Need: Troubleshoot what changed (imports, versions, timelines)
  Tool: Solution History
  Why: Shows who imported what, when, and what happened during import

• Need: Move solution content between environments as part of a consistent ALM workflow
  Tool: Solution Transfer Tool
  Why: Standardizes Dev → UAT → Prod transfers so it’s repeatable, not vibes-based

Pre-flight checklist (do this before you touch anything)

• ✅ You know whether you’re shipping managed or unmanaged (and why).
• ✅ You have a release solution pattern (don’t deploy from Default Solution).
• ✅ You’ve thought about dependencies (forms/views/scripts/flows/portal bits).
• ✅ You’ve documented: version, scope, and rollback plan.
• ✅ You are not making changes directly in Prod like it’s 2014. (Respectfully.)

Consultant law #2: If you can’t explain what’s inside the solution, you are about to deploy a surprise party.

Tool 1: Solution Components Mover

(build clean deployment solutions without missing stuff)

What it’s for

Quickly moving components into a solution so your deployment package is complete and intentional.

When to use it

Use it when:

• You built something (JS/form/view/table) but it’s scattered across the org
• You need to assemble a deployable solution from work done by multiple people
• You want to avoid “works in Dev, missing in UAT” failures

Avoid it when:

• You’re unsure which components are truly in scope (that’s how bloat happens)

Step-by-step (clean release solution pattern)

1. Create or open your Release solution (e.g., ClientName - Release - 2026.02).
2. Use Solution Components Mover to add:
   • the primary components (tables/columns/forms/views)
   • the supporting components (web resources, processes, security roles if needed)
3. Run a dependency sanity check (don’t rely on hope).
4. Export from Dev → import to UAT → validate → then Prod.

Common gotchas (ask me how I know)

• “I added the form but not the web resource.” Classic.
• Dependencies are sneaky: you’ll miss one ribbon command or one JS library and the whole thing behaves “interestingly.”
• Solution bloat: if you add everything “just in case,” you’ll hate yourself later during troubleshooting.

Validation checklist

• Open the UAT form/view and confirm:
  • scripts load
  • events fire
  • columns exist
  • no missing dependencies errors
• Confirm the solution contains only what’s in scope (not your entire life story).

Real scenario

You deploy “a small JS fix” and UAT says the button does nothing. You forgot the web resource. Solution Components Mover helps you package the missing piece cleanly without exporting the entire org.

Tool 2: Solution History

(what changed? who imported? when did this start?)

What it’s for

Viewing solution history/details so you can troubleshoot:

• what was imported
• when it was imported
• and why something changed “mysteriously”

When to use it

Use it when:

• A user reports a change and you need timestamps/version clues
• You want to validate that the right version actually hit UAT/Prod
• You’re investigating “why did this break after deployment?”

Step-by-step (deployment receipt workflow)

1. Open Solution History.
2. Filter to the specific solution name.
3. Note:
   • version number
   • import timestamps
   • any failures/warnings
4. Compare to your release notes (they should match—ideally).

Common gotchas

• People deploy hotfixes and forget to document them.
• Solutions get imported out of order (hello, missing dependencies).

Validation checklist

• The version in the environment matches what your release notes claim.
• If there was an issue: you can point to the exact import event that correlates with it.

Real scenario

“Prod started doing this last week.” Solution History shows the exact day/time a new version landed. Suddenly the investigation is… not vibes-based.

Tool 3: Solution Transfer Tool

(move solution content between environments, repeatably)

What it’s for

Supporting ALM workflows for moving solution content between environments in a consistent way.

When to use it

Use it when:

• You have multiple environments and want a repeatable workflow for transfers
• You’re tired of “did we export the right one?” chaos
• You want to standardize deployment steps for your team

Step-by-step (standard ALM workflow)

1. In Dev: finalize changes, publish customizations.
2. Export solution (managed/unmanaged per your strategy).
3. Import into UAT.
4. Validate (smoke tests + targeted business scenarios).
5. Import into Prod.
6. Post-deploy verification (version + behavior).

Common gotchas

• Managed vs unmanaged confusion causes layering surprises.
• Imports succeed but components aren’t active/published the way you expected.
• Environment-specific settings (env variables, connection refs) need governance.

Validation checklist

• The solution version matches in UAT and Prod.
• Key user scenarios work.
• No unmanaged layer drift was introduced (or if it was, you intended it).

“Deployable solution” recipe (copy/paste)

1. Start with a release solution.
2. Add only what’s in scope + required dependencies.
3. Publish + export.
4. Import to UAT.
5. Validate top scenarios + smoke tests.
6. Import to Prod.
7. Confirm version + one “golden path” scenario.
8. Document it (release notes, links, version).