The cost of hard-coded configuration
File server moves should not feel like a archaeology.
The Storage department renames \\fileserver01\Sales to \\fileserver02\Sales, and suddenly you are digging through logon scripts, GPO Preferences, Intune scripts, ConfigMgr packages, shortcut definitions, scheduled tasks, and that one mysterious script nobody wants to touch because “it has always worked.”
The risky part is not usually the change itself. It is finding every place where the old name was copied.
What you really want is simple: FileServer = \\fileserver02
Then every drive mapping, shortcut, script, and condition reads that value when it runs. Change the value once, and the workspace follows along. No treasure hunt. No ancient UNC path fossil hiding in an old OU.
That is exactly where worXpace Variables come in.
The problem with hard-coded workspace configuration
Typical Windows environments have plenty of ways to push configuration. Active Directory and Group Policy apply settings. Intune and ConfigMgr deploy scripts. Custom tools fill in the awkward gaps.
But in many environments, shared values are still scattered everywhere.
A file server name might appear in:
-
a drive mapping
-
a shortcut
-
an application wrapper
-
a script
-
a scheduled task
-
a site-specific exception
At first, this works. Then ‘time’ happens.
One location gets updated. Another does not. A pilot script becomes production. A temporary workaround quietly becomes “business critical.” Multi-tenant or multi-site environments add even more places for values to drift.
I’m using the file server name as an example here, but the challenge is generic and the result is familiar: a simple infrastructure change turns into a refactoring project.
worXpace gives you a cleaner option: treat configuration as data instead of repeated text inside scripts.
Meet worXpace Variables
In worXpace, a variable is a named placeholder written like this: %FileServer%
You can use variables in almost any property of a Task, Action, or Scope. When the workflow runs, worXpace resolves the variable to its current value.
That means your Network Action, File Action, Shortcut Action, Script Action, and Scope logic can all refer to the same shared value.
Instead of writing this everywhere:
\\fileserver01\Sales
You use this:
%FileServer%\Sales
Now the server name lives in one place, not in every corner of your workspace setup. That is configuration management with fewer hide-and-seek sessions.
Next, you can update your Actions to use %FileServer%.
For example, a drive mapping can point to:
%FileServer%\Sales
A shortcut can point to:
%FileServer%\Apps\FinanceTool
A script can read the same value instead of carrying its own hard-coded copy.
Later, when the storage department moves the share to:
\\fileserver02
you update the variable. That is it. Existing Tasks and Actions pick up the new value at runtime.
Variables are not just for paths.
Centralized values are useful for much more than file servers.
You can use them for site codes. A scripted variable called SiteCode could read a registry key or Active Directory attribute and return values like AMS, LON, or NYC.
Then a Scope with a Variable Criterion can decide which Tasks apply to which site.
Using the Variable Criterion
The Variable Criterion lets worXpace check whether a variable exists or whether it matches a value.
For example:
SiteCode equal to AMS
When configuring the Variable Criterion, enter the variable name without the percent signs. So use SiteCode, not %SiteCode%.
The criterion can check conditions such as:
-
exists
-
equal to
-
not equal to
-
starts with
-
ends with
-
contains
worXpace evaluates variable sources in a consistent order: internal- and custom variables first, then environment variables, then tenant parameters.
That consistency matters. The same name resolves the same way wherever you use it, which is exactly what you want when your workspace starts growing legs.
Practical patterns
File server or DFS root move
Create a variable called FileServer.
Use %FileServer% in Network and File Actions.
When the server or DFS root changes, update the parameter and let the existing workflow continue to run.
Site-based targeting
Create a scripted- or registry variable called SiteCode.
Have it read the value from a registry key, AD attribute, or another reliable source.
Use a Scope with a Variable Criterion to route Tasks by site.
For example:
SiteCode equal to AMS
If the script might take a moment to return the value, enable the Wait option on the Variable Criterion so worXpace can pause evaluation until the value is ready.
Choosing the right variable type
Use internal variables when you need built-in context, such as user, computer, session, or application details.
Use Base custom variables for values you set or calculate once and reuse throughout the session.
Use Volatile custom variables for temporary values that only matter during one Task or Application run.
Use tenant parameters for centrally managed values that should be consistent across devices and sessions, but may change over time.
Use environment variables when other Windows tools, scripts, or legacy processes also need access to the value.
The rule of thumb is simple: if a value is shared, do not bury it in a script. Give it a name and manage it properly.
Start small
You do not need a grand migration plan to benefit from this.
Pick one annoying hard-coded value. A file server. A web application URL. A license server. A feature flag. Anything that makes you sigh when someone says, “We need to change this.”
Create a custom variable for it.
Update one or two Tasks or Actions to use the variable instead of the literal value.
Then, the next time that value changes, notice the difference.
You update one parameter instead of chasing strings through scripts, policies, packages, and shortcuts.
And just like that, your workspace becomes a little less brittle, a little easier to manage, and a lot less fond of surprise archaeology.