Notifications Settings allows the team Admin to create system notifications for any of the existing Apps in the Servis.ai account. You can fully customize the message displayed to team members and create role-specific notifications.
User Permissions: Only the team's Admin can create new notifications.
Navigate to Notifications
Go to Settings > Advanced > Notifications.
Create a Notification
To create a New Notification click the 'Add Notification' button.
The Add Notification window will appear. Let's go through all of the fields.
1. App
From the dropdown, select the App for which you are creating the notification.
2. Name
Give your notification a name. This name will appear on the Notifications Settings page for your team members to see.
3. Description
Add a description that helps your team members identify the purpose of the notification.
4. Icon
Select an icon from the list, you can also search by key words.
5. Message Template
This will be the message displayed in the notification bell once the event occurs. If you want to add the name, ID, or other information about the record type {{ and select the desired option.
Note: This Field is historical, meaning it stores the message and keeps track of other the messages contained in this field in the past.
You can also do something we call Dot.Walking. You can learn more about it here:
Here's an example of using two Curly Braces {{. Once you type them in you'll be presented with a list of Fields to choose from.
You can even add prior values to your message. When editing the message template just type prior. and the system will show you all the available values. In the example below I want to show the old Sales Stage compared to the new one the Opportunity record was just changed to.
Note: Prior values are available in the message template only & not available in the body template.
6. Body Template
Here, you can write anything you want the notification to convey. The key difference from Message Template is that the Message acts as the main subject of the notification, while the Body serves as an optional description. The Body field is not mandatory and can be left blank if not needed.
Note: All variables used in the body reflect the current state of the referenced record, while the message retains a historical value.
7. Roles
By default, the 'All Users' option is added. However, you can select specific roles that should have access to the notification.
Want to know more about Roles? Check this article from our Knowledge Base.
8. Trigger
There are 3 different triggers available:
After Create - The notification will occur if the conditions are met after a new record on the selected App is created.
After Update - The notification will occur if the conditions are met after a record on the selected App is updated.
On Create or Update - The notification will occur if the conditions are met once a record is created or updated.
9. Conditions
You can specify as many conditions as necessary for your notifications. All of these will need to be met for the notification to trigger.
Note: In Boolean algebra, logical AND is treated like multiplication, and logical OR is treated like addition. As a result, logical AND has higher precedence, just as multiplication is prioritized over addition in arithmetic.
Field
Select the fields that will have an impact on the notification.
This usually includes the field selected under 'On update Fields' when you are expecting a specific value.
Operator
Select from the available options. The operators available will depend on the type of selected field.
Value
Select the value required for the condition to be met.
The options available will vary according to the field type.
Notification Example
Lets create an example for the following use case:
An admin wants to notify users when a new Opportunity is created or updated, but only under specific conditions:
- The status of the opportunity must be “Open”.
- Notifications should go to:
- A group (e.g., Sales Team) if the opportunity owner is part of the group.
- An individual (Current User) if they are the opportunity owner.
First Setup
The admin tried to create a single notification rule to handle all cases:
Conditions
(Status = Open AND Opportunity Owner = Current User)
OR (Opportunity Owner = Current Group Member)
CONDITIONS |
||
---|---|---|
Field | Operator | Value |
Status |
Is |
Open |
Opportunity Owner |
Is |
Current User |
Opportunity Owner |
Is |
Current Group Member |
This rule sounds correct at first glance. It tries to notify users when:
- The status is “Open”, and the opportunity owner is the current user, or
- The opportunity owner is part of the group.
Why This Doesn't Work
The issue lies in how the system combines the AND and OR conditions. In Boolean logic, the rule effectively evaluates like this:
(Status = Open AND Opportunity Owner = Current
User) OR Opportunity Owner = Current Group Member
Here’s the problem:
- The “Opportunity Owner = Current Group Member” part doesn’t depend on the status being “Open”.
- If the opportunity owner is in the group, the rule will trigger the notification—even if the status is “Closed”.
- This means users might receive notifications they shouldn’t, like for closed opportunities, which can cause confusion.
Solution: Two Different Notifications
To fix the problem, we split the logic into two separate notifications, each handling a specific case. This ensures the conditions are evaluated correctly, and no unnecessary notifications are sent.
First One: Notify the Group
Sends a notification to the group (e.g., Sales Team) when:
- The opportunity is open.
- The owner of the opportunity is part of the group.
Conditions
(Status = Open AND Opportunity Owner = Current Group Member)
CONDITIONS |
||
---|---|---|
Field | Operator | Value |
Status |
Is |
Open |
Opportunity Owner |
Is |
Current Group Member |
Why It Works:
This ensures notifications for the group are only sent when the opportunity is open.
Second One: Notify the Individual
Sends a notification to the individual (the current user) when:
- The opportunity is open.
- They are the owner of the opportunity.
Conditions
(Status = Open AND Opportunity Owner = Current User)
CONDITIONS |
||
---|---|---|
Field | Operator | Value |
Status |
Is |
Open |
Opportunity Owner |
Is |
Current User |
Why It Works:
This ensures individuals only receive notifications for opportunities they own, and only when those opportunities are open.
Final Combined Logic
Since the system treats multiple Notifications as OR (i.e., any notification can trigger independently), the combined logic becomes:
(Status = Open AND Opportunity Owner = Current Group Member) OR (Status = Open AND Opportunity Owner = Current User)
When Status = Open:
- If the owner is in the group, the First One triggers.
- If the owner is the current user, the Second One triggers.
When Status ≠ Open:
- Neither the First nor the Second triggers, so no notifications are sent.
Why This Solution is Correct
- Clarity: Each rule has clear, focused conditions.
- Avoiding Overlap: Notifications for the group and individuals are handled separately.
- Correct Behavior: Notifications are only sent when the opportunity is open.
Subscribe to Your Notifications
Now that your notification is set up, users can subscribe to it from the Preferences menu. To learn exactly how to do this, please refer to this article.