As we know by now, when adding elements to a solution, we can only capture security roles from the root business unit. This is a limitation of the solution package, and we have ways to work around it for most situations. For example, if we want security roles to be solution aware, even though we need them in child business units, we create them in the root business unit. They are inherited to the child business units, and we can assign the users at the business unit where we need them to have the respective security roles.
Unfortunately, one overlooked aspect is the role based forms. While the scenario described above works fine for users and security roles, once we bring into our equation role based forms, the whole pyramid collapses. Lets look at an example.
We’re going to start with a set of business units as described in the screenshot below.

As we can see, we have the root business unit called very creatively me4co. Right below this, we have the following child business units: Finance and IT. And just to make it more interesting, we have the following three child business units underneath the IT business unit: Cloud, Delivery and Infrastructure.
Now let’s create a few security roles. Go back to Settings > Security and choose Security Roles. Here we see the default security roles on an organization, all under the root business unit. We’ll come back to this view in a moment.
Once we’ve seen the default security roles, let’s go and create some new roles in the context of a solution. So, go to Settings > Solutions. Create a new solution if one is not already available for playing with. In this solution go to Security Roles. Once there, create a New role and name it creatively role1. For business unit, leave the root business unit. Click on Save and Close. I’m not going to assign any permissions here, i’m just using it for demonstration purpose.
Same way as before, go ahead and create a new security role. Keeping in line with our extremely creative naming convention, name this one role2. Only this time, instead of leaving the default business unit, change it to Cloud. This is a 3rd level down business unit, having IT as parent, which in turn has me4co as parent (the default business unit). Again, hit Save and Close. Now, looking at the solution, this new role called role2 does not appear in the Security Roles part of this solution. This is because only Security Roles in the default root business unit are being captured in a Solution package. To verify that our newly create security roles was indeed created, navigate to Settings > Security > Security Roles. Select from the Business Unit drop-down the root business unit if not already selected, and observe that role2 is also missing. But if you change the business unit to Cloud, now you will also find role2 in the list. See the below screenshot.

Now, with all these items setup and ready, let’s have a quick look at role based forms.
Go to Entities in your solution, select Add Existing, and select Contact.  When prompted to select entity assets, do not select anything, as we’ll just add a brand new view.

Entity Assets is a new feature added  with Dynamics 365, as part of enhancements to the Solution package model.

Click on Finish. Go to the Contact Forms, and add a new Main Form. Click on Save As, and name this form to RBF (short for role based form, but you can name it anything you want).Save and Close this form. In the Active Forms view for Contact, select this newly created form, and click on Enable Security Roles in the ribbon. The new screen that opens up allows you to choose a security role. Unfortunately, you only have a choice from the security roles created in the root business unit. No option to change the business unit selection. This relates to the fact that security roles in child business units are not captured in a solution package.

Conclusion: part of a Solution package, you cannot assign security roles to a role based form if the security role is not part of the root business unit.

But, if you really, really, really need to do this, you can still do it outside of a solution package. Do keep in mind that this configuration can not be ported to another organization through the use of a solution package. If you need this kind of configuration, you will have to manually implement if in all instances (dev, qa, uat, prod)… ugh…
Instead of doing this as part of the existing solution, let’s go back to Settings > Customizations. Select Customize the System instead. These customizations are applied directly to the root solution. Find the Contact entity, go to Forms and find the RBF form we’ve created earlier. Observe how the form created in an unmanaged solution is also present in the default solution.
Now, when you click on the RBF form and select Assign Security Roles, you will find role2 in the list of roles, as shown in the screenshot below.

Once you Save and Publish your customizations, your newly created role based form is available as defined.
Use this approach with care, and only if really necessary. The fact that this configuration can not be captured in a context of a Solution package, and can not be ported to another environment/organization is a major downfall, and it goes against best practices regarding solution management and deployment models.
Enjoy!