Data security
This content is for Spring ’26. Switch to the latest version for up-to-date documentation.
Aforza’s Ava is able to provide such compelling insights and actions due to its ability to access certain information and perform specific tasks across the existing Aforza platform. Aforza provides an end-to-end platform that encompasses Retail Execution, Trade Promotion Management, Digital Asset Management, and everything in between. Ava is able to call upon these existing applications and their underlying data to enhance her capabilities.
While Ava has the ability to harness this information, we also recognise that the user calling on Ava might need to have restricted access or permissions. To that end, Aforza has built a comprehensive data security model and capabilities to let you control in granular detail what each user should be able to do.
Ava Permissions
Section titled “Ava Permissions”Ava cannot access your Aforza applications at all until a specific integration has been set up as per the setup guidelines. This means that initially, any user using Ava is completely cut off from viewing any data within Aforza. Whilst Ava is still useful in this mode for supplying important information about your company, she is unable to access or use any real business information. Your company and administrators need to specifically choose to allow Ava to access these systems and the underlying information.
Once connected to the Aforza applications, Ava must then be given specific access rights to any underlying data or actions you want her to be able to perform. For example the Ava Sales Agent would need access to:
- Read Accounts
- Read Create Orders
- Read Products
- Read Pricebooks
- Create ContentVersions
You can choose to give as much or as little access to Ava as you require. If Ava does not have access to, for example, ‘Create Orders’, she will not be able to create new orders in the system. The Sales Agent will still work correctly, but when trying to create an Order will tell the user that it was not possible. In this way you have granular control over Ava’s precise capabilities. This level of control can be applied to Objects, Records, and Field Level Security, giving you very fine grained control on Ava as a whole.
User CRUD Permissions
Section titled “User CRUD Permissions”In addition to Ava’s global permissions, you can then also set user specific permissions. The user permissions use Salesforce Permission Sets to control what they are allowed to access within the context of Ava. For each user using Ava, you can provide a permission set containing their exact Created, Read, Update, and Delete permissions. These permissions will take precedence over any of their existing permissions. So even if a user can normally create orders, you can still limit them from creating orders through Ava. The following objects can all be controlled using CRUD permissions:
- Accounts
- Visits
- Products
- Orders
The following objects are always enabled globally and cannot be changed:
- Users
- ContentVersions
These top level CRUD permissions should be treated as the users gateway into the specific actions that Ava can take.
User Record Level Permissions
Section titled “User Record Level Permissions”If the CRUD permissions are the checkpoint into Ava’s data access and actions, Record Level Permissions are the secure exit that strips out any sensitive or restricted information. If a user is not able to see specific records or related information (e.g. Invoices on an Account), the record level permissions will strip out all of this information prior to it being sent to Ava. This means that a user is never able to see any data they should not have access to. Please keep in mind that if the data is too restrictive it will severely impact what Ava is able to do and the advice she can provide to the user.
Permission Exceptions
Section titled “Permission Exceptions”While using the above strategies gives you extremely granular control over what Ava, and the requesting User, is able to see, there are certain pieces of information that must always be provided in the response, regardless of the user’s security. This information is critical for the operation of Ava so must be included in the response. For example, OrderItems must always have a Quantity and UnitPrice. Even if the user is restricted from those fields, they are still sent to Ava so she can process the Order correctly.
In addition to field exceptions, in some cases, additional object data will be retrieved for Ava that is not specifically controlled via the CRUD Permission Set or Record Level Permissions. For example, retrieving a Product will also retrieve its related PricebookEntries.
The data retrieved tends to be operational in nature and consists solely of Aforza standard fields. A full list of the response fields can be provided upon request.