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

Notifications

Announcements

No record found.

News and Announcements icon
Community site session details

Community site session details

Session Id :
Dynamics 365 Community / Forums / Finance | Project Operations, Human Resources, ... / Error While assigning ...
Finance | Project Operations, Human Resources, ...
Answered

Error While assigning Role to User using odata : Warning: Security role '' with identifier value 'LedgerAccountant' is not valid..

(0) ShareShare
ReportReport
Posted on by Neeraj D 85

I am trying to assign a SecurityRole to the user using the oData rest endpoints. Here are the details:

  1.  URL: https://<trial-tenant>.trial.operations.dynamics.com/data/SecurityUserRoles
  2. Http Method: POST
  3. Json Body::{
        "SecurityRoleIdentifier":"LedgerAccountant",
        "UserId":"NDTestUser"
    }

When I trigger this request, I get following error:

"message": "Write validation failed for table row of type 'SystemSecurityUserRoleEntity'. Infolog: Warning: Security role '' with identifier value 'LedgerAccountant' is not valid..",
            "type": "Microsoft.Dynamics.Platform.Integration.Services.OData.AxODataValidateWriteException",
But, when I add SecurityRoleName in the request, my request is getting successfully executed. While inspecting the metadata for
EntityType name="SecurityUserRole", I saw that only UserId and SecurityRoleIdentifier are mentioned as key, then why SecurityRoleName is required in
the POST request to successfully assign the Role to the User?
I have the same question (0)
  • Verified answer
    André Arnaud de Calavon Profile Picture
    André Arnaud de Cal... 301,171 Super User 2025 Season 2 on at

    Hi Neeraj,

    There is an intended validation on the data entity. There is a double check by providing both the SecurityRoleIdentifier and SecurityRoleName. See also the validation used:

            // not valid if there is a role where identifier matches but name doesn't OR where name matches but identifier doesn't
        select firstonly RecId, Name, AotName from securityRole where 
            (securityRole.AotName == this.SecurityRoleIdentifier && securityRole.Name != this.SecurityRoleName) ||
            (securityRole.Name == this.SecurityRoleName && securityRole.AotName != this.SecurityRoleIdentifier);
        if (securityRole && securityRole.RecId)
        {
            return checkFailed(strFmt("@Security:SecurityUserRoleEntitySecurityRoleInvalid", this.SecurityRoleName, this.SecurityRoleIdentifier));
        }

  • Neeraj D Profile Picture
    Neeraj D 85 on at

    Thanks Andre for you response. It helped me a lot.

    Regards,

    Neeraj

  • Greg's Mom Profile Picture
    Greg's Mom on at

    What is the purpose of this check?  I understand you don't want to associate a user to a role that doesn't exist but why does it stop you from associating to a role that does exist and there happens to be another role with the same name?  So, if I have a custom "project manager" role and disable the standard "project manager" role, I cannot import an association to my custom one?  Is there any good way around this other than changing my security role name?

    Shouldn't this check be more like

    select firstonly RecId
from securityRole
where securityRole.AotName == this.SecurityRoleIdentifier
&& securityRole.SecurityRoleName == this.SecurityRoleName;

if(!securityRole.RecId)
{
    return checkfailed('the role doesn't exist');
}

  • André Arnaud de Calavon Profile Picture
    André Arnaud de Cal... 301,171 Super User 2025 Season 2 on at

    Hi Brawndo,

    It would be best practice to have unique role names. If you have a custom project manager role, use any naming convention to prevent looking at several records with the same name. Use e.g. "(CustomerName) project manager" or "(Abbreviation) project manager".

  • Greg's Mom Profile Picture
    Greg's Mom on at

    Thanks, Andre.  That makes sense.  Is this best practice published anywhere by microsoft or just more of a common sense thing?  I agree, we have run into a problem distinguishing between our custom roles and standard roles in the past and had to personalize the role lookup to include the AOT name to distinguish between them so the best practice does make sense.  

  • André Arnaud de Calavon Profile Picture
    André Arnaud de Cal... 301,171 Super User 2025 Season 2 on at

    Hi Brawndo,

    It is not documented by Microsoft. If you had to change the role lookup, you already should have be aware that something was not correct.

    In the 'en-us' language, all role names are unique. In some translations, there were duplicates in the past, which also caused various issues.

    Some setup, like workflow assignments and privacy access settings do store the role names. These could make wrong interpretations as well.

    So, common sense and experience.

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…

Congratulations to the November Top 10 Community Leaders!

These are the community rock stars!

Leaderboard > Finance | Project Operations, Human Resources, AX, GP, SL

#1
André Arnaud de Calavon Profile Picture

André Arnaud de Cal... 467 Super User 2025 Season 2

#2
Martin Dráb Profile Picture

Martin Dráb 420 Most Valuable Professional

#3
BillurSamdancioglu Profile Picture

BillurSamdancioglu 241 Most Valuable Professional

Last 30 days Overall leaderboard

Featured topics

End-of-life Announcement for Microsoft Dynamics GP

Product updates

Dynamics 365 release plans