Monitoring (for Admins)

Monitoring allows you to monitor the content of SMS messages that are coming in and going out of the accounts within your group. We provide the ability for you to write custom patterns using regular expressions that will be compared to messages, and when a match is found you can choose to just be notified of the message, or to have the message held for you to review. When you review a message you can reject it with a reason, or accept it.

The very first step you will want to do is add the email fo the person(s) you would like to receive notification if a monitoring pattern is detected. You can add multiple email addresses by separating emails with a semicolon.  (ex. jon@ionlake; jane@ionlake.)

Next you will want to add patterns. Click on the "Add Pattern" button.

You will now be able to enter the name of the Pattern and the Regex pattern. 

For example, if you wanted to add a pattern to be notified of any messages that contain a string that could be a social security number (SSN), you would put SSN in the name field, .*\d{3}-\d{2}-\d{4}.* in the pattern field.

You would now be able to choose to Hold the message until reviewed or plain Reject the message upon it being identified.

(Example of message pattern for social security number)

Note: We chose to use regular expressions because they will allow you, as a group administrator, to match anything that you need to. At the end of this document we will provide you with some example of regular expressions that you can use as starting points.

After defining your patterns, they will be compared to all incoming and outgoing messages within the accounts in your group. Whenever a match is found, you will receive an email at the email address you provided.

If a match is made with an outgoing message, and the pattern has the HOLD setting set to true, the message will not be sent to the desired recipient(s). An email will be sent to the account email address informing them the message needs to be reviewed. You will also receive an email, and you will need to review the message and either choose to RELEASE it, or REJECT it. If you release it, the message will be sent, if you reject it, a dialog will appear where you can provide a reason for the rejection. The rejection notice will also be sent to the email address for the account.

If a match is made with an incoming message, and the pattern has the HOLD setting is set to true, the message will not be available to the account. An email will be sent to the account email address informing them that they received a message, the number it came from, and that it is being held for review. You will also receive an email, and you will need to review the message and either choose to RELEASE it, or REJECT it. If you release it, the message will be viewable in the account, if you reject it, a dialog will appear where you can provide a reason for the rejection. The rejection notice will also be sent to the email address for the account.

You will now be able to see all matches and select the message you would like to review. If you choose to reject the message you will be prompted to enter a reason. Click continue. The MyRepChat user will be notified that their message was rejected via Email. 

If a message that is sent or received matches a pattern that does not have the HOLD MESSAGE turned on, the message will be sent/received normally, and you will get an email notifying you of the match. You will be able to go in and view the matching message, and clear it from your list.

What does the client see if they sent a flagged message? 

What does the advisor see if they were to receive the flagged message?

If the incoming message is rejected the advisor will receive a notification email. 

Regular Expression References

Please visit the below document for sample Regex information: 

https://ionlake.zendesk.com/hc/en-us/articles/360031442771-Regex-Simplified-by-Jonny-Fox-

A test page to try out changes:

https://regex101.com/

Commonly Used Patterns in MyRepChat

MyRepChat doesn't automatically create patterns for you to use since everyone's needs are different and regex allows (requires) you to be very specific about what you want. pre-built pattern may be too general for some and too specific for others. This may lead to false positives or false negatives. 

Some parts of the pattern you'll almost always want to include:

• (?si) modifier at the beginning. This makes your pattern case insensitive and will treat new lines like ordinary whitespace. 
• Use .*? at the beginning and end of your pattern and use \b to create a word boundary. This matches anything (including whitespace) and makes your pattern a 'contains' but keeping your pattern separate from the words around it. In other words, you probably want to reject a message that has a SSN anywhere in the message and not just if it's ONLY the SSN.

A few patterns to start with:

• SSN: (?si)^.*?\b(\d{3}[\s.-]?\d{2}[\s.-]?\d{4})\b.*?$
• DOB: (?si)^.*?\b(0*[1-9]|1[012])[-\/.](0[1-9]|[12][0-9]|3[01])[-\/.](19|20)\d\d\b.*?$
• CC: (?si)^.*?\b[0-9]{4}[\s.-][0-9]{4}[\s.-][0-9]{4}[\s.-][0-9]{4}\b.*?$
• Emoji: (?si)^.*?([\uD83C-\uDBFF\uDC00-\uDFFF]+).*?$

These are fairly generic patterns and before using them, you should understand the gotchas and if you need to, modify them to workout any conflicts or issues you may have. A few gotchas with these:

• the SSN pattern matches (optional) delimiters of whitespace, dot, or dash
• the DOB pattern only supports mm/dd/yyyy format
• the CC (credit card) pattern will match any 4 4 4 4 with space, dot, or dash delimiters.
• The emoji pattern matches on the unicode surrogate pairs where emojis are. Note: There is other things in this range but it's outside of normal language.

WIth each of these you could get much more specific or generic if necessary. For example, each credit card company has a specific pattern they support. This lack of specificity will probably not matter for most uses - you want to flag something that looks like a credit card number, it doesn't necessarily have to be a valid one.

Hints:

• Don't try to do too much with a single pattern. Usually it's better to add another one than to have a bunch of ORs. Its a little less efficient but more readable and easier to troubleshoot why something matches/doesn't match.
• Be as generic as you can get away with. This helps readability and troubleshooting. 
•  Think about typical numbers or patterns that you want to let through that may come close to patterns you are blocking. For example, is there a reference number you want to let through that is a 9 digit number that may match a SSN without delimiters? This is obviously a trade-off of the 'generic' hint.