Pooled Contractor Subscription/License
1 vote
We work with many business applications supported by a variety of external vendors. These vendors occasionally need remote access to provide technical support. However, the current monthly user‑subscription model is not an effective fit for support contractors for a couple reasons:
• Most contractors would only use Devolutions Workspace or Remote Access once or twice per year, typically during troubleshooting or upgrade activities. In some cases, for certain vendors/contractors, access is not needed at all in a year.
• For security and auditing purposes, we maintain named accounts for each contractor. A single vendor may have 10 or more individual contractor accounts as part of their support team, even though only one contractor provides support at any given time.
Because of this, maintaining long‑term monthly subscriptions for 100+ rarely used accounts is not cost‑effective and more users than our actual IT team.
A limited pooled or concurrent‑use licensing model—where licenses can be checked out automatically as needed—would be far more practical and aligned with our usage patterns.
While we could manually assign and remove licenses to vendor users before each support session as a workaround, this becomes inefficient at scale, especially when managing hundreds of vendor accounts or handling urgent support situations.
We are open to alternative solutions that would better accommodate these infrequent and unpredictable vendor access requirements. Thank you.
All Comments (2)
Hi,
Thank you for laying out the contractor scenario so clearly, including the specific math. Paying for 100+ rarely used vendor seats, more than your actual IT team, is exactly the kind of distortion the per-user model was never meant to create, and I agree it needs a better answer.
We do not want to introduce a true floating or concurrent-use licensing model. The complexity it adds (license servers, token tracking, edge cases around connection drops and offline use) creates more problems than it solves for the broader customer base, and we want to keep our store and licensing model simple. That said, I think we can address your underlying need without going there.
Here is the direction I would like to propose:
- Pair our existing Contractor feature with automatic license removal after a configurable inactivity window (think 7, 30, 60, or 90 days, whatever fits your support cadence). The license auto-assign capability we already have would then re-attach it on the next sign-in. In practice, you would keep your 100+ named contractor accounts for audit purposes, but only the contractors actively working in a given window would consume a license. The rest would release automatically. The auto-removal piece is not on our roadmap yet, but it is the kind of request that can move things forward, and cases like yours help us prioritize it.
- Steer contractor accounts to the Remote Access license rather than the full Remote Desktop Manager license. Lower price point, and it matches the actual scope of what a session-based support vendor typically needs. If a particular contractor truly needs the full RDM feature set (managing their own connection library, advanced session types, etc.), you can still assign RDM selectively rather than across the board.
The net effect is close to a pool, without the operational complexity of floating licenses. You would not need to manually assign and remove licenses before each session, which is the real pain point you raised.
Does this direction line up with what you had in mind, or are there pieces of the workflow it would still miss?
Best regards,
David Hervieux
+1 vote for solution on this front