François Dubois

Hello,

My understanding is that you want a user group to have access to every vault. This is already possible with the new role-based permission system (DVLS 2026.3+). Add the following role assignment under Administration – Configuration and security – Role assignments:

• Role: Vault member

• Scope: Workspace

• Assignees: My_User_Group

Note that a Workspace-scoped assignment applies to all vaults, existing and future, not only those created by non-admin users. Entry permissions defined inside each vault still apply.

French:

Ma compréhension de votre besoin est qu’un groupe ait accès à chaque voûte. C’est déjà possible avec le nouveau système de rôles (DVLS 2026.3+). Il suffit d’ajouter l’assignation de rôle suivante dans Administration – Configuration et sécurité – Assignations de rôles :

• Rôle : Vault member

• Portée : Workspace

• Assignés : My_User_Group

À noter : une assignation au niveau du workspace s’applique à toutes les voûtes, existantes et futures, et pas seulement à celles créées par des utilisateurs non administrateurs. Les permissions définies sur les entrées de chaque voûte continuent de s’appliquer.

Hello,

Thank you for your request. Could you let us know which type of workspace you're using? This is already possible in DVLS. During the Gateway installation in Devolutions Console, you have a field to set that information.

Does this address your need?

Best regards,

Hi,

Thank you for your request. Could you let us know which type of workspace you're using? This is already possible in DVLS. You can configure retention policies for recorded sessions under Administration > Database retention policies, in the "Privileged sessions monitoring" section.

Does this address your need?

Best regards,

Hello,

Thank you for the feature request. Historically, we haven't supported third-party providers in our web-based versions for various reasons, but we take note of your request and will follow this thread.

Best regards,

Hello,

Thanks for the feedback.

Supporting this would be a significant change on our side, because of the way our permission model is built today: an entry is only visible if its parent is visible, and that parent in turn is only visible if its own parent is visible. Visibility cascades down the hierarchy, so granting access to a single sub-entry without exposing the parent folder isn't something the current model allows out of the box.

The feedback is noted and appreciated.

Best regards,

Hello,

Thanks for your request.

At the moment, our permission model is built around hierarchy: to access a sub-entry, a user needs at least read/view access on its parent. That parent visibility is currently a structural requirement of how access is resolved, so granting "Connect/View" on a single entry while keeping the parent folder fully hidden isn't something the platform supports today.

We've taken note of your request and will keep an eye on this thread.

Best regards,

Hello Marcel,

Good news on this one: the "On close" and "On idle" disconnection options for the Password Manager browser extension have been implemented in a recent version.

You can configure them here

Apologies for not coming back to update this topic once it shipped. Don't hesitate to let me know if the behavior matches what you were looking for.

Best regards,

Bonjour,

Oui, c'est notre intention de travailler sur cela pour notre prochaine version qui est planifiée pour septembre. Nous faisons beaucoup de changements UI et faire plusieurs sélections est une amélioration que l'on désire ajouter.

Salutations

Merci pour votre demande.

J'ai créé un ticket pour y travailler prochainement, c'est quelque chose que l'on peut améliorer assurément.

Merci

Hello,

Good news, this is already supported in Devolutions Server! You can find the instructions here:

https://docs.devolutions.net/server/web-interface/administration/configuration/server-settings/security/conditional-access-policies/#configure-multifactor-authentication-from-the-web-interface We support IP addresses as rule.

I hope that helps. Let us know if you have any further questions!

Best regards,

Hello,

Thank you for the additional context, it really helps clarify the use case.

Just to make sure I understand correctly: would creating a dedicated group directly in Entra ID to wrap those existing groups be an option in your environment, and then synchronizing that group into DVLS? Or is the constraint that your Entra group structure is managed externally and cannot be modified to accommodate DVLS-specific groupings?

Understanding this will help us better assess the value of building native nested group support in DVLS.

Best regards,

Hello,

Thank you for sharing this. Your case is a real issue explaining why this feature matters. Unfortunately, I'm sorry we don't have more to share at this time. We don't have an ETA yet, but I want to assure you that this is still on our development list and hasn't been forgotten. We'll update this thread as soon as we have news.

Best regards,

Hello,

Thank you for your patience and for following up on this.

We do not have an ETA to share at this time, but we are planning to include this feature in our fall major release.

We will keep you posted as things progress.

Best regards,

Hello,

Thank you for the suggestion! We appreciate you taking the time to share your feedback.

While we definitely understand the appeal of having the VMware Dashboard available directly in the Devolutions Server web interface, we don't have anything planned in that direction at the moment. That said, we'll be keeping an eye on this thread to gauge interest from other customers, it helps us prioritize.

Best regards,

Hi Arnaud,

Thank you for your continued patience on this request.

Regarding your question about the Contractor tag: you are correct that it was recently added, but it is specifically designed for users of type Contractor (a Devolutions user type), so it is not an adapted solution if your users are Active Directory users.

As for the difference between the External and Contractor tags, the distinction is subtle. The Contractor tag is intended only for users of the Contractor type and serves mainly as an informational indicator. A small bug currently allows it to be applied to any user, but this will be corrected in an upcoming release. The External tag, on the other hand, is the appropriate one to use in situations like yours, where users are of a different type (such as AD-synchronized accounts).

As for the user expiration feature itself, we don't have an ETA at this time, but we should be able to add it to all user types in the short term.

Best regards,

Hi Arnaud,

Thank you for following up! Custom tags for users have not been implemented yet, and we don't have an ETA at this time. We have many priorities to balance across our development cycles, but we are monitoring this thread to gauge interest from other users.

We will make sure to update this thread as soon as we start working on it.

Best regards,

Hi Jimmy,

Thank you for following up! This feature has not been implemented yet, and we don't have an ETA at this time. We have many priorities to balance across our development cycles, but we are monitoring this thread to gauge interest from other users.

We will make sure to update this thread as soon as we start working on it.

Best regards,

Hello Arnaud,

Thank you for checking in, and I understand the frustration after four years!

Unfortunately, we still don't have an ETA for this improvement. We manage a large number of feature requests and prioritize based on overall interest and impact across our customer base. We continue to monitor the forum to gauge how many users share the same need.

Rest assured, we'll update this thread as soon as we make progress on this one.

Best regards,

Hello Arnaud,

Thank you for following up, and sorry for the wait!

I have good news: we recently introduced a Contractor user type in Devolutions Server, which natively supports an expiration date. This is a great fit for your use case with external consultants and MSPs who need temporary access.

This was intentionally our first step toward broader user expiration support. Our goal in the short term is to extend this capability to all user types, not just contractors.

We'll keep you posted here as we make progress on that.

Best regards,

Hi John,

I checked the ticket status, and it is currently planned to be addressed before the next major release, which is scheduled for June. Please note that timelines may change, but this is our current plan.

Let us know if you have any questions.

Best regards,

Hello John,

Thank you for your request.

Devolutions Server already supports modern authentication with Azure (Entra ID) for SMTP, which aligns with OAuth-based authentication. You can configure it using an Azure app registration (Client ID, Tenant ID, and permissions such as Mail.Send).

You can find more details in our documentation here. Would this approach meet your requirements?

Best regards,

Hello,

Unfortunately, there is no update on this at the moment. The retrieval of sensitive data from password lists via the REST API is still pending and has not been scheduled yet for an upcoming release. We will update this thread as soon as we have more information.

Thank you for your patience.

Best regards,

Hello,

Thank you for following up on this.

Over the past few releases, we have been laying the groundwork for it. The first implementation will focus on requesting an MFA when checking out a PAM entry, and it is planned for our next major version, expected in June.

Please don't hesitate to reach out if you have any questions.

Best regards

Hello,

Thank you for your suggestion. This is not a product development that is currently planned. We’re taking note of your feedback and we will follow this topic to see if there's any additional interest or input from other users.

Best regards,

Hello,

The Generate button is available only when a password policy is set on the entry. Otherwise, since the system does not know how the password should be generated, the password generator opens automatically. This is likely the behavior you observed.

If you are evaluating a migration to Devolutions Server (DVLS), have you tried migrating your database from RDM to DVLS using the Devolutions Console? Given the difference you noticed with the password generator, I suspect that you may have started with a new DVLS instance. Am I correct?

A full migration can indeed be performed, and you can find the detailed steps in the following documentation: Migrate SQL server to Devolutions Server

Don't hesitate if you have questions.

Best regards,