Fascinating! I would have thought one would take priority over the other but it seems to be more based on the sequence based on your testing. 

Is there a Web Filter option within the Managed Configuration option exposed by the App Catalog rule? Perhaps you could put all of the configurations in one place. 

In the config section of Chrome for the app rule there is a section for blocking URLs and allowing URLs. It says to follow the format on this page - https://www.chromium.org/administrators/url-blacklist-filter-format  so i used "*" in the block section and "http://URL" in the allow section but it does not work...not sure what the proper format is supposed to be. 


Edit

I just figured it out i needed to use ["*"] and ["Http://URL"]

Edit #2

PS, Thanks for the advice!

The importance of policy conflict resolution is often overlooked.  A general rule of thumb of profile configuration payload is to manually avoid policy conflicts as much as possible. 

Just imagine you have profile 1 having a feature control payload that disables camera, and another profile 2 having a feature control payload that allow camera.  It is possible to deploy both profiles to the same device.  In such case, is the camera allowed or disabled?  Relying on the device/MDM firmware to resolve policy conflict is not recommended, as I could only find incomplete and vague conflict resolution guidelines for MDM developers from Apple and Google. What resolution algorithm/strategy should be used actaully depends on the nature of the policy- sometimes the most logical approach seems to be logically-AND, sometimes logically-OR, sometimes First-Come-First-Serve, and sometimes using the latest configuration, etc.

In MobiControl, some form of resolution at the profile payload level is that SOME payload types can only have one instance deployed on a device, and any subsequent attempt to deploy a second instance will fail.  Things get even more complicated when some MDM policies can get overridden with script commands, configurations from AppConfig/OEMConfig framework, etc.   In particular, AppConfig/OEMConfig compliant options set in the advanced tab of an Managed-Google-Play app in an AE App-Catalog rule are dynamically re-deployed as soon as there is any change, not just once after the app binary installation.  Also, script command configuring policy can be sent to the device anytime to override what has previously been set by a profile.  Taking all of the above into consideration, using the latest configuration (deployed from whatever means) seems to be the predominant resolution. 

One has to have a big picture of all of the above, and hopefully learn the knowhow to avoid incorrect policy set-up due to conflict(s) from his/her configuration practices.