CRM 2013 – security role upgrade error – New Forms insufficient permissions

I have seen this error pop up a few times on the CRM Forums and thought I would add here on the blog just to help publicise the problem and thankfully the solution

The solution was posted on the CRM forum by Scott Durow a CRM MVP who often swoops into forum posts to provide the answer when no one else seems to know the solution.  It’s been very interesting answer questions on the CRM forum because I have learnt a fair bit on CRM 2013 but trying to replicate the problems but I have also learnt a lot from the answers to forum posts given by the CRM MVP’s.

I recommend follow Scotts blog and twitter feed

So this was the forum post – Update and Insufficient Permissions

 

We just went through the CRM update last night and some of our members can not access the system due to ‘Insufficient Permissions’?  What is the issue causing this and what is needed to correct it to allow them access?  Thanks!

Scott’s reply was

It sounds like a known issue with custom security roles where you must add additional access after the upgrade. Compare your custom roles with the out of the box roles to find what is missing – see dynamicsuniversity.com/…/crm-2013-new-forms-insufficient-permissions

 The link Scott posted goes through in detail how to resolve this problem.  I have pasted a little bit but I recommend you go to the page to see the full blog post.  Basically the problem occurs if you use custom security roles, when you upgrade to CRM 2013, these security roles won’t have been granted access to the new features where as the default security roles will have.
 

If you use custom security roles as your only security roles in CRM 2011 then you may run into this permissions issue when you upgrade to CRM 2013 and use the new 2013 Account and Contact forms:

It is a nice generic error with no log file attached or available for download.

The fast solution is to give that user one of the default CRM roles like Salesperson

– See more at: http://dynamicsuniversity.com/blog/crm-2013-new-forms-insufficient-permissions#sthash.1iVXZ5HN.dpuf

 

10 thoughts on “CRM 2013 – security role upgrade error – New Forms insufficient permissions

  1. Maarten Docter February 13, 2014 / 10:34 am

    Hi Ben,

    I was just reading your great post.
    Funny. We recently had this same error / problem in a CRM Online organization.
    We contacted Microsoft support and (after some research based on our solution etc.) they told us, that it was caused by some Quick (Create/Read) Forms that got security roles assigned.
    How this could be possible is still a mystery, because you can’t assign/enable roles to Quick Forms.

    ======================
    DISCLAIMER / WARNING:
    The solution (that Microsoft Support gave us) as described below isn’t tested yet.
    I still have to deploy our solution to the customer organization (CRM 2013 Online), to see if it really works. If so, I’ll add a new reply to confirm.
    NOTE: In our own on premise dev organization, we didn’t have this access issue. It only occurred Online.
    ======================

    They way to fix this, is by exporting your solution and modify the ‘customizations.xml’.
    Search for all occurrences of <Role> and you’ll find something like this:

    <forms type=”quick”> <!– or type=”quickCreate” –>
    <systemform>
    <formid>{fa1adaf8-0e78-4be6-9953-79ba47d2d23d}</formid>
    <IntroducedVersion>0.1.0.16</IntroducedVersion>
    <FormPresentation>1</FormPresentation>
    <FormActivationState>1</FormActivationState>
    <form>

    <DisplayConditions Order=”1″>
    <Role Id=”{627090ff-40a3-4053-8790-584edc5be201}” />
    <Role Id=”{119f245c-3cc8-4b62-b31c-d1a046ced15d}” />
    </DisplayConditions>
    </form>

    </forms>

    In the above fragment you see two roles in the element (and we didn’t put them there 🙂 ).
    You’ll have to replace those roles with the <Everyone /> element, to specify that the form is visible to everyone (duh..). See: http://msdn.microsoft.com/en-us/library/gg334497.aspx
    So you’ll end up with:

    <DisplayConditions Order=”1″>
    <Everyone />
    </DisplayConditions>

    Save your changes and re-zip the solution files. Import the zip file back into your organization and the fix is applied.

    Hope this helps.

    Maarten Docter

    FUNNY NOTE: After re-importing the fixed solution in our on premise dev org., I exported the solution again to see if the roles were really gone and didn’t reappear. While comparing the first exported ‘customizations.xml’ file with the new one, I noticed that some Dutch translations were missing in the first export and reappeared in the new export (we support Dutch and English). So the re-import seems to fix more than just access/role issues …

    Like

    • Hosk February 13, 2014 / 10:41 am

      Hi Maarten

      Thanks for you great comment, I can imagine there are going to be quite a few people coming up against problems like these when upgrading, so the more information the CRM community puts the better because at the moment it can be quite tricky to find help.

      I look forward to your next comment to see how you went.

      Ben

      Like

      • Maarten Docter February 13, 2014 / 10:52 am

        You’re welcome Ben. As soon as I deployed it, I will reply here.

        Can you please moderate/edit my reply so the XML shows up correctly? Commenters aren’t allowed to insert code fragments. 😦

        Like

    • Maarten Docter February 19, 2014 / 8:00 am

      Last friday we deployed the fixed solution to our customers CRM Online organization. And I can confirm that the proposed solution, as described above, works. So the disclaimer can be removed.

      Like

  2. Seamus December 11, 2014 / 1:03 pm

    Hello there, do I have to do this for every single instance of <DisplayConditions Order=…. ? Also, if I do this will it have any implications for any exisitng valid/deliberate restrictions – eg any security roles I have assigned to forms via "enable security roles". Thanks

    Like

    • Maarten Docter December 11, 2014 / 1:34 pm

      @Seamus – No, you only do this for forms of type=”quick” or type=”quickCreate” (see the code fragment above). Normal forms can have security roles assigned (so leave those untouched), but these quick/quickCreate forms can’t and that’s why they should be fixed.

      Like

      • Seamus April 15, 2015 / 1:41 pm

        I am having this problem, – it is manifesting when connecting via the Outlook plugin (the error appears for anyone tryong to connect who does NOT have the System Administrator role) but I do not have displayconditions set on my quick/create forms. I DO have display conditions set on about 20 other forms though. If I change these to “Everyone” I am presuming I will lose the valid security roles I have assigned on these forms, and not be able to reapply them (because the problem will reappear). Microsoft themselves have directed me to your solution but I feel generally uneasy and a bit indignant at having to hack around at an xml file in order to solve a problem with their software!.

        Like

    • Hosk December 11, 2014 / 1:34 pm

      I think you need to do it for all occurrences

      I don’t think this will effect the others forms but once you import it you will be able to check

      Like

Leave a comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.