Emails can be sent from a form by combining triggers with email templates to make notification rules.

These can be configured to be sent to:

• Project Roles, i.e. all users within a Project Role
• The Submitter i.e. the user who submitted the issue
• The ticket handler, i.e. the person currently assigned 
• Email address, i.e. a specific email address that has been manually associated
• Form field, i.e. an email address or user selected within the form (the email entered on their profile)

Please note: It is not possible to use multiple select fields in notifications, one of the other attributes above will need to be used instead.

The contents of each email can be custom curated so your team can create bespoke messages to best fit your form's use case and how your users need to work with them.

By default, InfoCapture notifications are sent by email, but this can be changed to in system per notification if required.
 

---

Caveats

1. An Intranet user must be in a project role that is set to receive the notification and also has the 'view' ticket permission, otherwise, notifications will not be generated for them. (Emails to specific external addresses can be set up separately from this)

2. If a user does not have permission to see everything included in a template ie. every form field due to field visibility sets, the email will be sent but those fields will not be included. (Emails to specific addresses will also hide certain user data if included, see more information later in the article)

3. Any user will receive just one notification even if the rules show that they should in theory receive multiple. (This is to prevent spamming with notifications) The notification with the highest order in the list would be sent.

4. Notifications can only be set up on/for states or changes at submission or after submission. 'Being reported' will not work to send notifications.

---

Notification Templates
 

Notifications may be sent using the default template or a custom template.

The default template is hardcoded by the system and will only be sent if a form administrators have used the 'notify xxxx' about any change in the tickets' options, when a user has monitored a ticket or when the 'default' template has been set in notification rules:

 

In contrast, custom templates can be completely curated by administrators and their contents handpicked to suit your form.

They can appear as plain text or HTML.

Enter custom text into the subject and text body to give the information you want the recipients to see.

Certain expressions hardcoded by the system can be used, which will pull through specific data about your form for easy template writing. e.g. a link to the ticket in question, its ID number, who it is currently assigned to etc

See below how expressions have been chosen to pull through the template for the recipient to see and/or interact with:

 

How this appears to the recipient of the email:

 

Expressions 

Expressions can be shown in both the subject and the body of custom templates.

Common expressions:

• {issue:_id_} - ID of issue
• {issue:_id_in_project_} - ID in the project (with prefix)
• {issue:_reporter_} - ticket submitter
• {issue:_assigned_} - current ticket handler
• {issue:_status_} - current status
• {issue:_created_} - date of ticket creation
• {issue:_last_modified_} - date of last ticket modification
• {link:view_issue} - URL of "view ticket" page
• {issue:FIELD_SYMNAME} - pull through the value of a specific form field

 

Other Expressions

• {project:name} - name of the project
• {notif:header} - header of notification (for example, "Ticket has been UPDATED")
• {issue:_notes_} - notes of ticket
• {issue:_latest_note_any_} - if visible will include private notes
• {issue:_latest_note_if_public_} - if visible to the user
• {issue:_history_} - history of ticket
• {issue:_traffic_light_} - traffic light (if SLA has been used)
• {link:update_issue} - URL of 'edit ticket' page (so the user will open the ticket in edit mode)
• {link:change_status:STATUS_NAME} - URL to change status of ticket to STATUS_NAME
• {link:approve_status:STATUS_NAME} - URL to approve status changing to STATUS_NAME

 

Example

- Create template

I start with a trigger called New Ticket Submitted

From Admin > Infocapture > (my project) > Notifications, I click 'Add New Template'.

Custom text can be entered so the message is specific to the use case of my form.

I can bolster this and the overall usefulness of the notification by including expressions in the body of the template.

Simply click on each expression to see it included in the email template, and move this around as necessary to build out the notification.

These offer extra detail about what the notification is for and ticket information that is valuable for the recipient to know.

e.g.
A new ticket, {issue:_id_in_project_}, has been submitted by {issue:_reporter_} at {issue:_created_}
Its current status is {issue:_status_}
You can view the ticket here: {link:view_issue}

 

Once sent, the parts of the template seen in curly brackets will be automatically replaced with the requested information.

This template appears as below when received by users:

 

Create templates to serve different purposes e.g. one for when a note is added that goes to the ticket handler

This may need different information included than one that is sent to the submitter or other project role.

Create different templates to suit these needs based on the trigger and who is going to receive it.

 

 

- Create a notification rule

Now that I have a template created and a trigger to tie it to, I can click Add New Rule to set up a notification like so:

 

1. Choose the trigger that should send the email.
2. Choose the template you have created. Using a 'Default' template is an option which is explained in its own guide here.
3. Choose the project role(s) to notify. The email will be sent to all the users in the role(s) you select - remember that these roles are created and defined in the Project Permissions screen.
4. You can also specify email addresses here if you want to ensure that there is one address that will always be sent an email. This is useful for notifying those who are not on your intranet (such as external users), team distribution lists, and other responsible individuals who are not in a project role.
   Note: Whereas picking a project role (3) or a user select (5) the system checks that the stated users do have permission to see form content before sending an email, this function does not. More is described below.
5. If you have a user picker on your form, you will see it here. This is useful if your form has a field where the user states their manager, and you wish for that manager to be notified.

Click 'Add/change rule' to save.

The rule will appear listed in the 'notifications' tab on the admin side of the form.

Notification rules can be edited at any time by administrators.

 

- Test

Continue adding in your notification rules and associate the templates you have created as required until all those you need are listed.

 

Now submit test tickets in your form to check the notifications fire and send them to the expected users.

Remember the caveats that could prevent notifications from firing.

See our guide on troubleshooting InfoCapture notifications if your emails are not sending as expected.

Permissions checking

If you have made use of field visibility sets then Infocapture will check that the recipient has permission to see all the form content that is meant to be included in the email.

If they do not have permission to see everything, the email will not be sent.

There is an exception - if you have used the 'also send to email address' field (number 4 in the list above), which makes less comprehensive checks the email will be sent and only sensitive information like 'submitted by' and username will be hidden by default (if they were set to appear in the notification template)

This means if you are thinking about implementing the 'also send to email address' option make sure it is appropriate for them to see the ticket information you have included in the template as only certain elements will be obscured.

As an Example:

I have an email template that contains a field from the form called 'total approved amount'. 

I have a notification rule to send this to both of my project roles, called 'All users' and Managers'.

Within a field visibility set, I have created a rule that if the status is 'awaiting approval', those in 'All users' cannot see the 'total approved amount' field but those in 'Managers' can.

If a ticket is submitted and its initial status is 'awaiting approval', the notification will send to managers but not 'All users'.

This is because those in 'All users' don't have permission to see what's trying to be shown in the email template, so the notification is suppressed.

If a ticket is submitted and its initial status is something else, then the notification would go to 'All users'.

If there was no field visibility rule restricting the view of that form field then every role entered would get the email.

This logic is something to keep in mind when creating your templates, choosing expressions to include, the triggers they are being tied to and who you want to be sent it.

 

Priority

Every time a form is submitted, or edited and saved, the notification rules will be checked by the system so any triggers that now fire and have rules tied to them will send the notifications as appropriate.

An important element to understand is any user will receive just one notification even if the rules show that they should in theory receive multiple notifications.

There are 6 notifications listed in priority order, the highest first:

1.  Custom notification to the ticket handler
2.  Custom notification to the submitter
3.  Custom notification to any user specified in a form field
4.  Custom notification to a project role
5.  Default notification sent to those who are monitoring the issue 
6.  Default notification sent to the ticket handler and reporter based form settings

If a ticket action would trigger multiple notifications to one user, then the system will not send them all, instead, it will send only the notification with the highest priority order.

 

Processing

To change the order that notifications will be processed use the up/down arrows:

The priority rules will be applied as each is processed.

For a single run of the notification checking, once one email has been sent to a user the system won't send a different notification.

If the recipient is not a user and is instead sent to a custom email address via 'Also send to email address' in the IC notification editor, this will be sent each time (as there are no permissions check for this facility)

If a notification is based on an action that happens in more than one page load the system may send more than one notification to the same user too. e.g. a status change might send user A a notification.

When the background task next runs this might pick up an SLA traffic light change due to the status change and result in another notification being sent to that user.

 

Recommended next article:
Default Notification Templates