How Configuration Changes Synchronize

When a GENESIS PowerShell command succeeds, the change it makes is immediately committed to the configuration database. You do not need to save or apply it separately: a New, Set, or Remove command writes through the same FrameWorX configuration path that Workbench uses, so as soon as the command returns without error, the configuration is changed.

Understanding what happens after that point matters because it tells you when a change becomes visible to operators, to runtime services, and to the next command you run. The behavior is identical to editing the same configuration in Workbench; PowerShell is simply a different way to reach it.

What to Expect After a Command Runs

  • The configuration database is updated at once.

    The command operates on live configuration, not a local draft. A subsequent Get command—in the same session or a different one—returns the new state.

  • The running system picks up the change the way it does any configuration edit.

    Subsystems that support online configuration changes reflect the update without a restart. Where a subsystem applies configuration when its project or service loads, the change takes effect the next time that load occurs, exactly as it would for a Workbench edit.

  • Security is evaluated on every command.

    Each command is checked against GENESIS security. If the signed-in user is not allowed to perform the action, the command is refused, and nothing is written—the same restriction that applies in Workbench.

Local and Remote Targets

By default, commands act on the configuration of the local server. The interface uses FrameWorX client/server communication, so the same commands can target a remote system. Get-WbHost reports the host your commands are currently configuring, and Set-WbHost retargets the session to another host. After retargeting, every subsequent command applies to that host's configuration and synchronizes there in the same way.

Why This Matters for Scripts and Automation

Since each command commits as it runs, a script applies its changes incrementally rather than as a single transaction. A script that creates an asset and then several properties leaves the asset in place even if a later command fails. This makes verification an important habit: read back what you changed, and design routines so they can be safely re-run. These practices are especially important when an automated agent is driving the interface—see Using PowerShell with an AI Agent.