Summary

This article will describe how e-mail sub-addressing can be used to influence where e-mail messages from ClinSpark are sent. It is a unique way to define and manage how certain e-mails can be delivered to the same underlying inbox that an authorized user has control over.

What are e-mail modifiers?

E-mail modifiers are a way to change how an e-mail address is defined in order to ensure that an alternate definition of the address routes messages to the same inbox. This is a mechanism also called sub-addressing, plus addressing, or tagging.

A valid email address is usually defined through a prefix and domain, separated by the @ symbol.

jane.smith@clinspark.com

Given the above:

• jane.smith is the prefix

• clinspark.com is the domain

Using a modifier symbol in the prefix, such as + , along with a string of characters after the modifier, allows you to define an alternate address while still routing messages to the same underlying inbox.

Here’s an example of the same e-mail address with modifiers:

jane.smith+test1@clinspark.com

The modified address contains +test1 in the prefix.

Given the above:

• jane.smith+test1@clinspark.com is still considered a valid email address

• Messages sent to jane.smith+test1@clinspark.com will route to the same inbox as jane.smith@clinspark.com

How are these useful?

Using this mechanism, users can create a unique email address “on the fly” but still ensure that messages coming from ClinSpark route to the same underlying mailbox. Modified addresses could be considered temporary (or disposable) for certain use cases, or, perhaps defined with a more specific purpose long term.

ClinSpark allows modifiers to be used in the definition an e-mail address, and is considered valid, so long as the e-mail still passes the unique requirement enforced in the user interface.

Open

ClinSpark accepts the use of modifiers in e-mail addresses, so long as the modified address is unique.

Modified e-mails also are acceptable for workflows where authentication requirements (for example, MFA or password reset) are placed on accounts that route a message to an inbox under the ownership of the same user who is managing the account. In the examples used in this article, ‘Jane Smith’ is still the same person who is able to receive messages to their inbox, and would be able to successfully confirm their identity and ownership of the account when completing authentication workflows.

For testing purposes, it may be useful to setup multiple different ClinSpark user accounts in this way in order to ensure that e-mail messages routed through various account actions are accessed by the same authorized user. Additionally, when testing bulk e-mail workflows for recruitment messages, a single ‘tester’ can access the messages intended for multiple different volunteer recipients that are setup with modified emails.

It may also be useful for certain ClinSpark users to be setup with different accounts using modifiers in their username/email address, so they can access those accounts for different purposes. This would be beneficial only under circumstances where existing user account controls for site/study restrictions are not able to achieve the appropriate level of account security to access data in the system. For example, a CRA may need to be given multiple accounts to properly access the system for their level of involvement and support with certain studies and/or sites. When necessary, those users work with their ClinSpark system administrators and study teams to setup and use multiple accounts, and determine an acceptable convention to use for e-mails and username. Such as jane.smith+study1@iqvia.com, jane.smith+study2@iqvia.com, etc.