As mentioned in the Policy Builder Overview section, there are 4 types of policies: Call, Data Analytics, Digital and System. Most apps and containers are available in Call policies. Data Analytics has the extra Debug app but not all of the containers and apps. Digital Policies are used if your org it utilising any Natterbox’s digital channels. Finally, System policies are created when the app is first installed and are used to route default options.
This chapter covers the standard apps and containers (apart from the system defaults because they are available on app installation). If you are looking for how product-specific apps work, you can find them in their product chapters:
Policy Containers
Receiving Containers receive calls from elsewhere and are configured at source.
Stand Alone Containers allow for specific items to be placed in the container without need for an App.
Simple Containers only give the option to change the Name of the container.
Functional Containers and Apps (all Apps are functional) have scope for individual configuration to route or otherwise affect the call.
Container | Found | Available Policies | Configuration | Link | Contains Apps? |
|---|---|---|---|---|---|
From Policy | Automatic insertion | Call, System | Receiving Container | ✓ | |
Start block | Call, System | Stand Alone Container | ✓ | ||
Inbound Digital Address | Start block | Digital | Stand Alone Container | ✓ | |
Extension Number | Start block | Call, System | Stand Alone Container | ✓ | |
Invokable Destination | Start block | Call, System | Stand Alone Container | ✓ | |
From SIP Trunk | Start block | Call, System | Receiving Container | ✓ | |
Link tab | Call, Data Analytics | Simple Container | ✓ | ✓ | |
Switchboard | Link tab | Call, System | Functional Container | ✓ | ✓ |
To Policy | Link tab | Call, System | Simple Container | ✓ | ✓ |
Link tab | Call, Data Analytics, System | Simple Container | ✓ | ||
Inbound Message | Start block | Data Analytics | Stand Alone Container | ✓ | |
Event | Start block | Data Analytics | Stand Alone Container | ✓ | |
Natterbox AI | Link tab | Call, Digital, System | Functional Container | ✓ | ✓ |
DDI Numbers | Automatic insertion | System (‘DDI Calls’ policy only) | Stand Alone Container | ✓ | |
Catch All | Automatic insertion | System (‘Default Inbound’ policy only) | Stand Alone Container | ✓ | |
Outbound Numbers | Automatic insertion | System (‘Outbound Calls’ policy only) | Stand Alone Container | ✓ |
The Start Block
Every policy must start with either an app from the Start block or the From Policy receiving container.
Call Policy | Data Analytics Policy |
|
|
Digital Policies | System Policies |
|
|
The Link Tab
If the Link tab is available in any container or app, it give different options depending on what policy you are using.
Call Policy | Data Analytics Policy |
|
|
Digital Policies | System Policies |
|
|
Above the Or create new Container field is a dropdown list which displays what happens to a call after it has gone through the current container. By default this option is Hung Up - this makes sure that if a call has nowhere to go, it is terminated correctly. As new containers are added, this list is populated. If a link is automatically connected, the selected option in the list changes to match. This list always reflects the route of the connector.
Please note: Many of the apps have a Link tab, however, each is configured individually - by default, the call is passed to the next app in the container (or to the container itself) to further the call; however, in the case that they fulfil certain configuration but do not have a connector to move the call forward, the call is hung up.
System Policies
When the Natterbox app is installed into Salesforce, the system automatically creates 7 system policies, listed below. There are 3 call policies and 4 digital policies; they have the same capabilities as a normal policies and can be edited if necessary. However, each policy has a specific purpose within the system.
This policy makes sure all DDI calls that are made are connected correctly through the system.
In addition to the start block, this policy has a container called DDI Numbers by default (instead of the From Policy container found in a normal Call policy). This leads to an Action container that holds a Connect a Call app, configured to Connect an inbound call routed via a DDI number to the DDI User.
This policy 'catches all' calls that are not covered by another policy and gives them a neat resolution, given that they won't be answered.
In addition to the start block, this policy has a container called Catch All by default (instead of the From Policy container found in a normal Call policy). This leads to an Action container that is named Speak, which holds a Speak app named This number is not in service, configured quite simply to say "This number is not in service".
This policy makes sure all calls that are being made to external (PSTN) numbers are connected correctly through the system.
In addition to the start block, this policy has a container called Outbound Numbers by default (instead of the From Policy container found in a normal Call policy). This leads to an Action container that holds a Connect a Call app, configured to Connect an outbound call made by a user to the Requested Number.
Contains the Lookup system components for each channel type which are used when a message is received on the appropriate channel for a Contact we cannot identify. For example if a message is received from an address that hasn’t messaged in before this will fire the relevant contact lookup based on the channel type.
Contains the Catch All system components which are used when a Digital address that is not assigned to a User or a Routing policy receives a message for a brand new conversation. This can also be used as a policy for routing individual addresses if needed but it’s recommended to keep these separated for organisation purposes.
This is the catch all for all unassigned WhatsApp or SMS numbers.
This is the origin of all outbound SMS and WhatsApp messages.
FAQs
How many apps can I have in a single policy?
There is no explicit limit on the components, it's reliant on the amount of configuration and the different types of components you're using, but the rough limit is about 100 components.
If your policy is approaching this amount we recommend you look to break out and simplify your rules where possible.
How can I duplicate a policy?
You will need to export the policy and import it into a new policy. This is outlined in the policy builder overview chapter.