RDM/DVLS: Ability to configure a deterministic default approver (user or group) for checkout amd approval requests

RDM/DVLS: Ability to configure a deterministic default approver (user or group) for checkout amd approval requests

1 vote

avatar

Problem
Approver users and groups can be configured correctly for an entry using:

  • Temporary Access = Allowed
  • Authorizers = Custom

This configuration is applied and respected.
However, when launching an entry that requires approval, RDM does not allow defining which approver (or approver group) should be selected by default in the checkout dialog.
Instead:

  • The first selected approver is chosen arbitrarily
  • The default selection may vary (user or group appears random from the requester’s perspective)

This makes the approval UX unpredictable.

Current Behavior

  • Multiple approvers (users and/or groups) are configured under Authorizers = Custom
  • At checkout time:
    • The “Send request to” field is auto-populated
    • The selected value is not deterministic
    • Admin cannot control which approver/group is preselected

The requester must manually adjust the target, even though the intended default approver is known in advance.

Requested Behavior
Allow administrators to configure a default approver (user or group) per entry, so that:

  • The checkout dialog always:
    • Preselects the configured default approver
  • Other approvers may still be available (unless restricted), but:
    • The initial selection is deterministic and intentional

This is specifically about default selection order, not about permissions or enforcement.

Scope

  • Temporary Access
  • PAM Checkout
  • Entry Access Approval
  • Applies to:
    • Connection entries
    • Credential / PAM entries


Suggested Implementation Options
Any of the following would solve the issue:

  1. Explicit default flag
    • Mark one approver (user or group) as Default
  2. Ordered authorizers
    • Allow defining priority/order and always select the first one
  3. Dedicated setting
    • “Default approver” field alongside Authorizers configuration


Value

  • Predictable approval workflow
  • Better UX for requesters
  • Eliminates accidental requests sent to the wrong approver/group
  • Especially important in environments with multiple approver groups

All Comments (3)

avatar

Hello,

Thank you for your request. I understand your needs and would like to provide some clarification. The current behavior is not consistent across all features. We implemented changes to the PAM Checkout process, and I am wondering if this approach could meet your requirements.

When a user submits a PAM Checkout request, the approver is now set to "All approvers" by default. This means the request is sent to all designated approvers simultaneously. The goal of this change is to accelerate the approval process: as soon as one approver is available, they can approve the request, allowing the user to continue their work without delay. This also removes the need for the requester to determine who the appropriate approver should be.

If we were to apply this same approval logic across all approval processes, would this solution work for you? Would it be acceptable for you if the default value for approvers were set to "All approvers" ?

Best regards,

François Dubois

avatar

Hi François Dubois

This is an excellent option if the default value for approvers is set to “All approvers”, and it would be great to see this implemented not only for PAM Checkout, but also for Entry access.

At the same time, while working with multiple customers on Devolutions integrations, I have encountered use cases where there is a need to select an individual default approver. From my perspective, this would be a very valuable addition alongside the option to have the default value set to “All approvers”.

Best Regards
Alexey

avatar

Hello Alexey,

Thank you for your feedback, it is very helpful. I agree that there are scenarios where having a single default approver, alongside multiple approvers, would be valuable. I will document this use case and follow up here once we have an update.

Best regards,

François Dubois