There are a a few different use cases where traffic may have to be sent to a particular destination using PBF rules, and it also has to be NATed. For example:

SMTP traffic should be sent to a security device (zscaler) in the LAN VR. Traffic for app1 should go DIA via the wan interface in transport VR T1. All other traffic should go DIA via the wan interface in transport VR T2.

As currently designed, NAT happens before PBF for a given session. When the first packet for a new session arrives, NAT module gets to see the packet before the session is created. It looks up the NAT rules, and if a rule matches, takes the corresponding action (for example, set up a NAT binding for the session). 

PBF module gets to see the first packet later, after the session has been created. At this time, it may be too late for PBF to select the next hop, since NAT may already have happened.

At a high level, NAT and PBF cannot be applied together for the same session. To achieve use-cases of the above type, 

1) Two sessions must be created. S1 in the LAN VR, and S2 in the appropriate transport VR. 

2) Ensure that NAT rules apply only for transport VR sessions, and not LAN VR sessions.

3) Ensure that PBF rules apply only for LAN VR sessions, and not transport VR sessions.

Consider this config: 

Interfaces: There are two paired tvi interface pairs

PT-LAN1, PT-T1 is a paired tvi interface pair to go from LAN VR to T1

PT-LAN2, PT-T2 is a paired tvi interface pair to go from LAN VR to T2

Zones: PT1-T1 in DIA-zone1, PT-T2 in DIA-zone2, Lan interface in LAN-zone

IP address of zscaler in LAN-VR: ZS1

R1: Match app1, source zone LAN-zone

set nexthop PT-LAN1

R2: Match app2, source zone LAN-zone

set nexthop PT-LAN2

R1: Match service SMPT, source zone LAN-zone

NAT via ZS1

R2: Match source zone DIA-zone1

NAT via T1

R3: Match source zone DIA-zone2

NAT via T2

Consider an SMTP session. When the first packet arrives, the NAT rule R1 will match, and create the NAT binding. Because interface NAT is being use, NAT module automatically sets the next hop interface to ZS1

Once the session is created, PBF policy lookup will happen, but will not match any rule. 

Traffic will be NATed and flow through ZS1 as expected. 

Consider an app1 session: When the first packet arrives, NAT rule lookup will happen, but not match any rule (all rules are source zone based). Session S1 gets created. Then, PBF policy lookup happens, and rule R2 is matched. The nexthop is set to PT-LAN1, and the traffic is forwarded. The traffic gets reinjected into transport VR WAN1, and creates session S2. Here, the ingress interface is PT1-WAN1, and egress interface would be WAN1. Thereforce, source zone based nat rule R2 will match, and NAT the traffic through WAN1. None of the PBF rules will match. 

The same thing happens for an app2 session.