Thanks for the feedback. The roadmap will largely be driven by customer requests for additional granularity, combined with the development capacity and priority within the relevant service team for the specific service where that granularity is required. ABAC is a framework that can be utilised by our service teams to deliver that additional granularity by specifying targets (API calls that we need to control/restrict) and by identifying and supplying the required attributes (pieces of data used for decision making purposes). The first step in that process is identification of needs. What are those areas in the product where additional access controls are required? Those requests, which should be channelled through the Product Ideas page, will be directed to the appropriate service team for prioritisation and implementation. That's a long-winded way of telling you that it is difficult to provide an overall roadmap of what additional capabilities will be delivered and when, via ABAC.
However, what I can say, at this point, is that we are currently in discussions with the Outbound team on a specific use case around additional restrictions for outbound campaigns and I expect this will be one of the next use cases we will add.
We are also working on delivering IP-based restrictions via ABAC. We already have an allowed IP addresses feature in the product but we can develop a more flexible solution via ABAC which will enable customers to apply more granular IP-based restrictions using either or both allowed and denied IP address scenarios.
Another area where we have a lot of requests for additional access control granularity is in the area of Quality Management. As you are probably aware, we already use permission conditions to provide additional granularity for some permissions in areas such as Quality Management and Workforce Management. In the longer term, ABAC will be used to provide further granularity, but we need to tread cautiously in the short term to avoid the potential for confusion between the two different paradigms. However, I expect we will start to see some use cases getting implemented via ABAC later this year.
So, get your thinking caps on. Where do you need additional controls applied? Be as specific as possible - what specific action needs to be controlled, why are these controls needed and what criteria (attributes) should be used to make the decision to allow or deny access?
One other important point to note is that ABAC is all about restricting what a user can do, not what a user can see. ABAC is invoked when a specific target (API or set of APIs) is called and will allow or deny access based on the policy conditions. However, if the user has been provided access to a given view, ABAC cannot be used to filter information on that view (e.g. it can't be used to hide or obfuscate information on a page), as there is no API call being made at this point to make an access decision about.
------------------------------
David Murray
Principal Product Manager
Genesys Cloud
------------------------------
Original Message:
Sent: 03-20-2025 14:30
From: Orhun Sahin
Subject: Using ABAC to prevent users from updating user profile fields
Hi David,
The level of granularity it offers for access control is a huge step forward. The initial focus on preventing unauthorized changes to profile fields and preventing non-admins to grant roles, is a great starting point for securing accounts and applying the rule of least privilege.
Yet, I'm curious about the roadmap for ABAC. The previous announcement itself mentions that "ABAC will evolve over time as more attributes and targets are defined." So, my main question, echoing yours, is: What other resources are planned for inclusion in the ABAC roadmap? For example, in PureConnect, we had granular access control over selectable statuses. We could define which user roles could select a specific status. This was incredibly helpful, and it's a capability we don't currently have in Genesys Cloud. Will ABAC be extended to allow this level of control over status selection?
Having a clearer roadmap would be extremely helpful for planning and understanding the long-term direction of ABAC in Genesys Cloud. A general timeline will also be helpful to plan our implementations.
In short, this is a promising start, and I'm eager to see how ABAC develops!
Thanks,
------------------------------
Orhun Sahin
Software Development Engineer
Original Message:
Sent: 03-20-2025 13:58
From: David Murray
Subject: Using ABAC to prevent users from updating user profile fields
The initial release of Attribute-Based Access Control (ABAC) enables administrators to prevent users from updating defined user profile fields. To support this use case we have added an ABAC template titled "Cannot Update Certain User Profile Fields". You can simply save this template as a policy to apply this restriction. However, you can also make changes if you want to restrict some, but not all fields in the user profile, for example. The purpose of this article is to provide additional information about the user profile fields to assist in this scenario.
But, before going into details on the user profile page, let's start out by defining what is and is not covered by the ABAC template/policy. As outlined in https://help.mypurecloud.com/articles/complete-profile-2/, to access your profile, click your profile picture in the sidebar, and then click the larger profile picture. ABAC can be used to restrict changes on this specific page. Other fields that are associated with the user but are not included directly on the profile page (e.g. WebRTC settings, as shown below) cannot currently be restricted via an ABAC policy. If you want to apply restrictions to WebRTC phone settings (or other settings that are not covered by ABAC at present), submit an idea via the Product Ideas page.
#Roadmap/NewFeatures
#Security
------------------------------
David Murray
Principal Product Manager
Genesys Cloud
------------------------------