Pages don't load with WCF and App Control enabled on the same policy. How to structure?

[IT_Manager]

I have a Fortigate 600C running 5.6.4 with a policy for a "Restricted Users" Active Directory group.  The policy is basically as follows:

Internal > WAN -

Source: LAN, WLAN, "Restricted Users"

Destination: Any

Web Filter: Custom_Restricted

App Control: Custom_Limited

I have several other policies with varying levels of restriction for different user groups.  My problem is with Facebook specifically, but potentially other sites.  Social media is blocked by both the WCF policy and App Control policy.  If a user under this policy tries to go to Facebook the page times out.  I've found that if I disable App Control, everything works fine and the "Web Page Blocked' page loads up like it should.  I've found posts and documents stating that there are problems with Proxy-based WCF and flow-based App Control on the same policy, and it would seem that's my problem.  

Obviously I don't want to disable App Control, and I've seen suggestions to create separate policies for WCF and App Control, but if I create two policies from Internal > WAN with the same source and destination, won't the traffic just hit the first rule and ignore the next one?  Am I understanding the way it works incorrectly?  My understanding is that it looks at the rules from the top-down, and the first rule it finds that applies to the traffic it stops there.  So if I put my WCF policy above the App Control policy, the App Control never gets applied, right?

[darwin_FTNT]

Right.

Can verify the policy matching order which is done in kernel. The cli debug command is 'diagnose debug flow ....'.  Once the session passed the policy, kernel will process the session.  If the policy specify proxy or flow-based, then the packet will be re-routed to wad or ipsengine for inspection.

For proxy based utm, the debug command is 'diagnose wad debug...'.  For flow-based utm, the debug command is 'diagnose ips debug ...'.  There is also the command 'diagnose debug application ...' but this is mostly for other daemons and can specify an integer parameter only.  For flow or proxy daemons, you can specify more categories.

Regarding the replacement message not showing up, it depends on when the utm is detected.  Some utm are triggered before client make http get requests and the session is blocked immediately.  For some session, if the client has received partial data already and then the utm is triggered, then replacement message can't be sent.

Would recommend to open a ticket to send config and the url request to trigger the block so can further verify the root cause.