Hybrid Admin Panel / Engineering

HAP began as automation and evolved into a platform.

The design preserves what made PowerShell valuable for systems administration while moving the core product toward a compiled, testable, protected, and deliberately extensible C# and .NET 10 codebase.

The practical starting point

PowerShell was the right origin because it was already where the work happened.

HAP started in PowerShell because Windows administration, Active Directory work, Exchange workflows, and automation-heavy operational tasks already lived there. It was immediately available, fit the creator's established experience, and made it possible to prove real workflows quickly against the problems HAP was built to solve.

Hybrid Admin Platform branding and theme settings window from the PowerShell and WPF implementation.
PowerShell/WPF implementation in the current build
Why PowerShell came first

It was natively available and operationally proven.

PowerShell was the creator's established tool for Active Directory, Exchange, onboarding, offboarding, diagnostics, and automation. It allowed HAP to begin as a solution to real administrative work rather than as a detached technical experiment.

  • Immediate access to established Windows administration modules
  • Fast iteration against real operational problems
  • A familiar language for proving workflows and provider behavior
  • A practical path from individual scripts to one connected interface
Why PowerShell alone was not the destination

The product needed a protected and durable core.

As HAP expanded, the core application needed stronger boundaries than a modifiable collection of scripts could provide. A dedicated codebase improves maintainability, packaging, testing, performance, code integrity, and control over the product's base behavior.

  • Compiled application and stable contracts
  • Clear separation between UI, application logic, domain models, and providers
  • Reduced risk of accidental or unauthorized modification to core behavior
  • A more predictable foundation for long-term support and release management

Layered architecture

Provider-specific details stop at the provider boundary.

Application services work through contracts and canonical HAP models rather than passing native objects from Active Directory, Graph, Exchange, or future systems throughout the application.

01User InterfaceHAP-owned views and interaction
02Application ServicesWorkflow orchestration and validation
03Domain & CoreCanonical models and platform services
04ProvidersTranslation to and from external systems

Controlled migration

Move by parity and cutover, not by rewriting everything at once.

The current PowerShell product remains the behavioral reference until each native .NET slice has contracts, tests, parity evidence, and an explicit cutover decision.

1

Define stable contracts

Separate provider and workflow behavior from PowerShell types and WPF controls.

2

Preserve current behavior

Use a temporary legacy bridge only where required during migration.

3

Build native providers

Implement first-party behavior in .NET after the existing workflow is understood and covered.

4

Cut over deliberately

Remove the legacy route only after native parity and operational validation.

PowerShell remains valuable

Move PowerShell from the core implementation to an extension boundary.

The long-term model is a protected first-party application core with customer extensibility provided through controlled extension points rather than direct modification of the application itself.

Approved registration

Only explicitly registered providers from HAP-controlled locations are eligible to load.

Declared capability

Provider identity, operations, configuration, runtime requirements, and grants are described through versioned contracts.

Out-of-process execution

Customer PowerShell providers run through a separate optional host rather than being imported into the main application process.

Contained failure

Process isolation helps contain hangs, crashes, global state, and dependency conflicts.

The reason behind the design

Protect the base product, preserve administrator trust, and still leave room for customers to connect HAP to the systems unique to their environment.

The result is intended to be a stable first-party platform with a controlled extension model—not an application whose core behavior depends on arbitrary scripts being loaded into its process.

Review operation and requirements Visit the Trust Center