stop the “who removed my software?” surprise
Self-service application portals are great.
Right up until one person clicks Unassign, a core application disappears from a shared PC, and the next group walks in asking the question every IT team loves to hear:
“Who removed my software?”
So, we have delayed lessons, interrupted shifts, and a little less trust in self-service than yesterday.
The problem is not self-service. Self-service is doing exactly what it was asked to do. The problem is treating every Windows device as if it belongs to one person.
On a personal laptop, removing an app usually means: “I do not need this anymore.”
On a classroom PC, nurses’ station, lab machine, or kiosk, it may accidentally mean: “Nobody gets this anymore.”
That is a rather dramatic difference for one innocent-looking button.
Where Service Point fits
In worXpace, the Service Point panel lets users assign and unassign applications in their personal workspace. When a user adds or removes an application there, worXpace triggers a Workspace Refresh. That refresh updates the user’s workspace items, such as shortcuts.
You can also publish an application with Uninstall on detach enabled. When that option is active, detaching the application can remove it from the device.
That is useful on dedicated machines, where the device and the user more or less belong together. The user removes the app, worXpace cleans it up, everyone is happy.
On shared PCs, though, that same behavior can be a little too enthusiastic. One user detaches the app, and the software may be removed for everyone who uses that machine after them.
That is not self-service. That is creating chaos with a friendly button.
Use %ContextTrigger% to tell the difference
This is where %ContextTrigger% becomes handy.
During a Workspace Refresh, %ContextTrigger% can tell you what caused the refresh, such as a Service Point attach or detach action.
That means you can make worXpace react differently depending on the situation.
For a personal device, you can keep the normal uninstall flow. If the user detaches the application, worXpace may uninstall it from the machine.
For a shared device, you can use a safer pattern. When %ContextTrigger% indicates a Service Point detach, worXpace can remove only the user-specific parts like shortcuts, profile settings, etc.. The actual application binaries stay on the device. You might even set the app to ‘Deny unassigned use’ for good measure.
In other words: clean up the user’s workspace, not the whole machine.
The shared-versus-personal decision can come from device groups, organizational units, or variables that describe ownership, role, or device type.
Example: a classroom CAD application
Imagine a hefty CAD application pre-installed on classroom PCs and published in Service Point.
Students can add it to their workspace when they need it. When they are done, they can detach it again.
With the shared-device pattern, worXpace sees that the detach action came from Service Point during a Workspace Refresh. Because the device is a lab PC, worXpace removes that student’s shortcuts and personal settings, but keeps the CAD software installed.
The next class signs in, opens their workspace, and the CAD application is still ready to go.
No lengthy reinstall.
No annoyances.
No “who touched the CAD app?” detective episode.
The result
This approach keeps self-service useful without making shared PCs unpredictable.
Users still get control over their own workspace. IT keeps control over what stays installed on shared devices. Support gets fewer surprise uninstall tickets. And everyone avoids the moment where one person’s cleanup becomes everybody’s problem.
For shared Windows machines, the rule of thumb is simple:
- Let users detach apps from their workspace.
- Do not automatically treat that as permission to remove the software from the PC.
That small distinction can save a lot of noise, tickets, and hurried reinstall work. In worXpace terms: use Service Point for personal choice, and use %ContextTrigger% to keep shared devices from becoming a software vanishing act.