Product Ideas Portal

Got an idea for a new feature? Maybe a tweak to make something work even better? Wish there was an integration with another product to make you even more productive? You've come to the right place.

The Product Ideas Portal lets you submit whatever product feedback you have, good, bad, ugly, and anywhere between.

Want to stay anonymous? Don't worry, no email address or name fields are shared on the public portal. You can create an account which lets you vote on other people's ideas and receive updates when your idea's status changes.

To learn more about how an idea becomes a feature, check out this infographic.


Approvers should be selected based on Requestors and not by the account.

Scenario:

Quick Group A contains: Privileged Account P1, P2, P3

Quick Group B contains: Privileged Account P2, P4, P5

Quick group A is assigned to Requester group A1 { req1 and req2} and Approver group B1 { App1}

Quick group B is assigned to Requester group A2 { req3 and req4} and Approver group B2 { App2}


If requester "req1" is raising the request for Privileged Account for P2, request reaches out to both approvers App1 and App2.”


Problem: Approval request is sent to both App1 & App2, while only APp1 should be getting the request because Req1 raised the request. App2 is irrelevant.


Justification:

In a typical RBAC model, the request should go to the approvers that are mapped to that Quick Group and not all the approvers in the company. The approvers for the same account are different because of the context in which they approve.

For e.g. Application team’s request to access P2@Server1 should be approved by the Application Team approvers and the same account when requested by Linux Team should be approved by the Linux Team approvers. This is essential because the Application Team approvers would know more about the activity done by the Application Team, similarly the Linux Team would know more about the activity done by the linux team.


We feel the current Behaviour is not correct for these reasons -

  • It does not meet the concept of a Role Based Access control model, where the approval should be routed based on who is requesting (role based).

  • Notifying multiple irrelevant approvers causes significant productivity loss as the irrelevant approvers might spent few minutes to read the notification before ignoring it.

  • Combining the irrelevant notification with an unfriendly mobile UI causes even more frustration to users.

  • Changing the process to meet the product’s behavior may lead to audit/compliance challenges.

  • Guest
  • Aug 10 2021
  • Future consideration
  • Attach files
  • Guest commented
    10 Aug 05:18pm

    To summarize, if a Privileged Account belongs to more than one team (i.e. if a privileged account is in more than one Quick Group) when a requestor in a particular team requests that account , the request goes to ALL the approvers of ALL the teams the account is in rather than just the approver for the applicable team.