InlineApplicationRecommendationSession1
{
"display_name": "Application Recommendation Example",
"description": "Recommendation created on 3/11/26, 2:43 PM",
"site_ids": [
"9e0865d0-9d89-44c7-8cc0-9f96a9b35721"
],
"start_time": 1772664273441,
"monitoring_enabled": true,
"action": "ANALYZE",
"recommendation_type": "APPLICATION",
"context_application": {
"id": "26ecd766-7340-40f9-8606-218acc036687",
"display_name": "My Application",
"site_ids": [
"9e0865d0-9d89-44c7-8cc0-9f96a9b35721"
]
},
"segmentation_strategies": [],
"connectivity_preference": "NONE",
"connectivity_preference_logging_enabled": false,
"exclude_multicast_flows": true,
"exclude_broadcast_flows": true,
"policy_type": "L4",
"additional_rules": [],
"use_private_ip_range_group": false,
"separate_rules_by_services": false
}The application provided by user that will be used to generate recommendation. For now we only allow user to start recommendation for one application. Once a context application is selected, no other context entity can be selected to start the recommendation.
The Security policies provided by user that will be used to generate recommendations. The applied-to scope of the context_security_policies can only be the application. Currently we only accept one security policy. If context_groups are also specified, then the context_groups should be equal to the applied-to members of the security policies.
Specifies the policy type for rule generation. If L7 policy type is selected and L7 context data is available for analysis, then L7 rules will be recommended. Otherwise, L4 rules will be recommended. L7 policies provide application-layer visibility and control, while L4 policies operate at the network layer.
Defines a list of granular segmentation strategies to be applied. This allows for a more customized security policy for the application, offering finer control than the general connectivity preference. Each strategy in the array specifies a rule for a particular traffic direction (like intra-application, ingress, or egress). The combination of these strategies dictates the final recommended security posture.
This field indicates the default connectivity policy for the application ALLOW_LIST - Adds a default drop rule DENY_LIST - Adds a default allow rule NONE - No default rules are added. This is the default setting
Enables logging to be turned on for the default rule added by connectivity strategy
If enabled, multicast flows will not be considered in the analysis
If enabled, broadcast flows will not be considered in the analysis
Port filter specifying filter type and a list of port filters
This list contains up to 25 additional rules, which are considered as additional default rules. Flows that hit default rules and these rules will be considered as unmicrosegmented. In section re-use, these rules will not be be picked for modification.
One example of a fully qualified path is: "/infra/domains/default/security-policies/east-west-security-policy/rules/ssh-protection-rule"
An example request object would be: "additional_rules": [ { "rule_path": "/infra/domains/default/security-policies/default-layer3-section/rules/default_rule_NDP", "site_id": "7937597f-9bbc-4ca3-9921-0bc68cce6f65" }, { "rule_path": "/infra/domains/default/security-policies/Test-Policy/rules/Test-Rule", "site_id": "7937597f-9bbc-4ca3-9921-0bc68cce6f65" } ]
When enabled, recommendation will use the global shared private IP range group to cover VMs and IPs seen in the leaked flows if no existing applications or tiers or groups can cover them. New groups will not be created. This can reduce the number of groups but may result in broader policy scope.
When enabled, each service gets its own separate rule even if they share the same source and destination. This creates more granular rules but increases the total number of rules. When disabled (default), rules with the same endpoints are combined into single rules with multiple services.