web
You’re offline. This is a read only version of the page.
close
Skip to main content

Notifications

Announcements

No record found.

Community site session details

Community site session details

Session Id :
Customer experience | Sales, Customer Insights,...
Answered

Delegated Admin vs. Non-Interactive User

(0) ShareShare
ReportReport
Posted on by 5

Dear fellow members, recently I have stumbled upon an issue with plugin user context. I have a plugin that reads from entity available only to administrator (lets call it "admin-available-entity"). This plugin is executed also by lower security roles. When running this plugin in "calling user" context, lower security role does not allow user to read from "admin-available-entity".

To ensure correct plugin execution I am running this plugin in context of "Delegated Admin". This seemed to be fine, but then I exported the solution with plugin and sent it to german customer. This customer has whole Dynamics instance in german language and user "Delegated Admin" does not exist in this instance. There is a german localized user name called “Stellvertretender Administrator”.

Therefore I cannot create a consistent installation package using "Delegated admin" context because of various user name localizations. So far I have checked following options:

1. run plugin in "system user" context like https://community.dynamics.com/365/b/dynamics365andazuresolutions/posts/d365-v9-x-quick-tip-how-to-run-a-plugin-in-system-user-context

2. create non-interactive user and run in context of this user - I cannot find if it is possible to add non-interactive user to a solution though

Could you please advise me best practice approach to have a solution with plugin running in administrator context? Without manually creating users in client's target instance.

I have the same question (0)
  • Verified answer
    Wahaj Rashid Profile Picture
    11,321 on at

    Hi,

    Thank you for your query.

    When you register a step to be executed in a specific user's context, that user must exist in the target environment.

    In your scenario, I would suggest you impersonate using code, instead of a plugin registration tool.

    When you obtain an organization service object in the Execute method of the plugin, instead of passing calling user, pass NULL in the CreateOrganizationService method.

    This will make sure the plugin runs in the context of the SYSTEM user (without security checks).

    Here is an excellent post in the same context:

    (+) D365 v9.x Quick Tip: How to run a Plugin in System User Context? - Microsoft Dynamics 365 Community

Under review

Thank you for your reply! To ensure a great experience for everyone, your content is awaiting approval by our Community Managers. Please check back later.

Helpful resources

Quick Links

Responsible AI policies

As AI tools become more common, we’re introducing a Responsible AI Use…

Neeraj Kumar – Community Spotlight

We are honored to recognize Neeraj Kumar as our Community Spotlight honoree for…

Leaderboard > Customer experience | Sales, Customer Insights, CRM

#1
Tom_Gioielli Profile Picture

Tom_Gioielli 170 Super User 2025 Season 2

#2
#ManoVerse Profile Picture

#ManoVerse 70

#3
Jimmy Passeti Profile Picture

Jimmy Passeti 50 Most Valuable Professional

Last 30 days Overall leaderboard

Product updates

Dynamics 365 release plans