Skip to main content
Question

Secuity for Business events and import scenario as a subcriber

  • January 29, 2026
  • 5 replies
  • 50 views

dgodsill97
Varsity I
Forum|alt.badge.img+5

I created a business event based on Vendor Price changes which executes an import scenariio to update a stock item custom field.  The user has delete access to both Vendor Prices and Stock Items however the business event does not fire.  If an admin changes the vendor price, the business event fires???

Does a user have to have access rights to both the BE and the import scenario subscriber?  I an not aware this is required since other business event fire.

5 replies

shushanna34
Freshman II
Forum|alt.badge.img
  • Freshman II
  • February 2, 2026

Hi, 
yes — effectively they do, and what you’re seeing is expected behavior.
Business Events run under the security context of the user who triggers them, not as a system/admin user.

So when:

  • A normal user updates Vendor Prices

  • The Business Event fires → it tries to execute the Import Scenario

  • Acumatica checks that user’s permissions for everything involved

If any permission is missing, the BE silently does not execute.

When Admin does the same change:

  • Admin has access to everything

  • The BE fires successfully

That’s exactly the behavior you’re seeing.
 

What access is required (this is the important part)

The user must have access to all of the following:

 Business Event

  • Screen: SM302050 (Business Events)

  • At minimum: View access

 Import Scenario

  • Screen: SM206036 (Import Scenarios)

  • At minimum: View + Execute

 Target Screens used by the Import Scenario

For your case:

  • Stock Items (IN202500) → Update rights

  • Any other screens referenced in the scenario

 DAC-level access (implicit but critical)

Even if they can delete Vendor Prices, they must also:

  • Be allowed to update Stock Items

  • Be allowed to update the specific custom field


MissyMain41
Jr Varsity I
Forum|alt.badge.img
  • Jr Varsity I
  • February 2, 2026

Hi, 
yes — effectively they do, and what you’re seeing is expected behavior.
Business Events run under the security context of the user who triggers them, not as a system/admin user.

 

 

This is exact opposite of my experience.

Business events fire using the global admin User ID, not the user logged in performing the task to trigger.
Was this pulled from an AI response perhaps? Either something changed in recent versions, or this AI response may be incorrect. Or maybe over all these years and all my testing somehow I have been incorrect, but I really believe from my experience testing business events that the global admin user ID is what controls business event triggers, that is the user that needs access. You can easily test this if you want. 


dgodsill97
Varsity I
Forum|alt.badge.img+5
  • Author
  • Varsity I
  • February 2, 2026

I am having an issue when the Stock Item screen opens as a pop-up, i.e., from a PO line,  The BE does not fire the first time when you change the field being tracked by the event, but fires the second time you change the field.  I have an open case for this.


shushanna34
Freshman II
Forum|alt.badge.img
  • Freshman II
  • February 2, 2026

Hi, 
yes — effectively they do, and what you’re seeing is expected behavior.
Business Events run under the security context of the user who triggers them, not as a system/admin user.

 

 

This is exact opposite of my experience.

Business events fire using the global admin User ID, not the user logged in performing the task to trigger.
Was this pulled from an AI response perhaps? Either something changed in recent versions, or this AI response may be incorrect. Or maybe over all these years and all my testing somehow I have been incorrect, but I really believe from my experience testing business events that the global admin user ID is what controls business event triggers, that is the user that needs access. You can easily test this if you want. 

Thanks for sharing your experience — that’s valid, and I agree that Business Events often behave as if they run under a system/admin context.

The difference appears when the subscriber is an Import Scenario. Import Scenarios are screen-based processes, and in practice screen-level and DAC-level security is enforced during their execution. As a result, even if the Business Event triggers successfully, the Import Scenario may fail to execute when the required permissions on the target screen or fields are missing.

This explains why the scenario works for Admin but not for a limited user, without contradicting how Business Events generally behave.

I looked for official Acumatica documentation that explicitly covers this behavior, but unfortunately could not find any. Everything I shared above is based on observed behavior and practical experience, and should be treated as a possible explanation rather than a documented rule.

Also, if you have the solution  or official reference for this case, please share — it would be much appreciated 🙂

 


MissyMain41
Jr Varsity I
Forum|alt.badge.img
  • Jr Varsity I
  • February 2, 2026

Hi, 
yes — effectively they do, and what you’re seeing is expected behavior.
Business Events run under the security context of the user who triggers them, not as a system/admin user.

 

 

This is exact opposite of my experience.

Business events fire using the global admin User ID, not the user logged in performing the task to trigger.
Was this pulled from an AI response perhaps? Either something changed in recent versions, or this AI response may be incorrect. Or maybe over all these years and all my testing somehow I have been incorrect, but I really believe from my experience testing business events that the global admin user ID is what controls business event triggers, that is the user that needs access. You can easily test this if you want. 

 

Also, if you have the solution  or official reference for this case, please share — it would be much appreciated 🙂

 

 

All of my experience is also from personal testing. Mostly when a BE triggers by record change or schedule, and not trigger by action.

For example, you could have a BE trigger by record change with an import subscriber, and your personal user has access to data provided through Branch access roles or restriction groups, but the global admin does not, I found it did not trigger.

The same goes for email subscribers too, especially ones that have reports attached. The general rule of thumb for trigger by record change/schedule has been the global admin controls this in the back end through the use of its currently active roles. If the global admin lacks a role or is not included in a restriction group that grants them access to certain pieces of data associated with the BE or subscriber it fails to trigger, once those roles are granted and the global admin then has access to that data it then is successful at triggering.