Skip to main content

Permission Issues on Posting after deploying Extension in Business Central Production Tenant

Introduction:
Issues when you deploy your app in Business Central Production VS Business Central Sandbox. Let us what are the implications of the statement.
In my last blog () I have already pointed out the difference in Profile as to how can create new Profile in Business Central Sandbox but the same is not possible in Business Central Production.

Pre-requisite:
Microsoft Dynamics Business Central (SaaS)

Demonstration:
1. I was working with General Journals after deploying the App in Production Environment.
Suddenly during posting I go this error.


2. To Verify this issue is not of Permission Set, I gave the User SUPER Permission and tried again.

I got the same error despite giving SUPER Permission. Again the same the error, so I checked the Effective Permissions.


I noticed that Table G/L Entry has an Indirect Permission.
I replicated the same Production in Sandbox. But I didn’t find any issue like this.


3. Moreover, I noticed that when I uninstall the App, the Production works perfectly and I cannot replicate the same in Sandbox hence no debugging.

4. I also noticed that there is something called as Entitlement which are more superior than Permission Sets.


5. There was also an ambiguity sometimes in Permission Sets after I remove the App from Production sometimes I could Effective Permissions for  G/L Entry as Indirect and sometimes I could see then as Yes(Enabled).

I  didn’t have any Option other than harassing Microsoft Support for this as my client was going live in next 20 hrs.

6. Microsoft’s Solution: Microsoft found that there should be Permission for the extension to Insert into G/L Entry.

With the help of Aananth Rajadevan(https://www.linkedin.com/in/aananth-rajadevan-a342265a/) from Microsoft Support, we collaborately figured out that since it is an Indirect Permission, we need to put the Permissions in the Object itself.

7. Finally adding Permission in the Objects as per the screenshot, this resolved the issue.



Output:


Conclusion:
From this I can conclude that there is a lot of difference between Sandbox and Production tenant. There are two ways of dealing with this.
1. Production and Sandbox Tenants need to be complete in Sync in terms of the Opertability.
2. Enable Debugging on Production so atleast the Partner can figure it out on their own.
Additionally(I say this from a Developers/ Consultants view here), give access to Global Administrators to Business Central Production / Sandbox through PowerShell so they don’t have to harass Microsoft Support everytime there is any issue.

Comments

  1. This is confusing, sorry.

    You did not explain which object you added permissions to and what that object does (related to the problem).

    ReplyDelete
  2. The Object here was an G/L Entry Table extension object.
    If I do not add the permissions in another object which creates,modifies and deletes the data in G/L Entry, I will be getting an error.
    So, I need to add Permissions in an object which is trying to access G/L Entry Object.

    ReplyDelete
  3. Well, that was always the case.
    Also with C/AL.
    And it was not mentioned that your addin creates it's own g/l entries.
    Therefore I was confused.

    ReplyDelete
  4. In the older versions of Nav it wasnt - super was it said on the tin. This has caught us out for the same reasons testing in sandbox was fine then permission issue in production not related to permission but entitlement, would be nice to apply this in sandbox (on and off as I can see sometimes you may not want it) so we dont hit it in production. Thanks for the post was beginning to think it was just us.

    ReplyDelete
  5. Well, good to hear that. Hope you got the resolution through the blog.
    Thanks.

    ReplyDelete

Post a Comment

Let me know your comments below. I'll try my best to answer your comment