...
It is highly recommended to register all expected DNS MX (Mail eXchanger) records at the start of the configuration process. For instance, customers will need to have a DNS email for PROD use, such as “clinspark-mail.customer-name.com”, and likely want to test this functionality first in Sandbox and VAL environments. For this, customers might also want to additionally register with SendGrid DNS records such as “clinspark-sandbox-mail.customer-name.com” and “clinspark-val-mail.customer-name.com”. It is better to perform this configuration task all at once in the beginning of setup, so that they will be ready when needed.
...
In the service desk ticket, customers should request that a member of the engineering support team be added to the account as an admin teammate for support purposes. Due to MFA requirements, these must be named users. We may add additional internal support users if needed, though with the appropriate subscription level, this is cost neutral.
| Note |
|---|
SendGrid validation logic will prevent the addition of an admin teammate email address that may already be in use on an existing customer account. This means that customers may need to use email modifiers to invite IQVIA support team members. For more information on modifiers (as ClinSpark also supports their use) see here: User accounts and e-mail modifiers To work around this, we recommend that customers add IQVIA support team members with a modifier in their account that reference the customer name. For example, if the support team member is john.smith@iqvia.com, the ‘teammate email address’ invite in SendGrid should be john.smith+customer@iqvia.com. |
Step 3: Customer DNS Admin provisions a DNS MX record with the Customer-owned ‘Main Domain Name’, enabling its use for email
Emails sent from ClinSpark need to come from a customer-owned non-ClinSpark DNS name, the ‘Main Domain Name’. For example, outgoing mail sent from clinspark ClinSpark might have a from ‘from’ address of “clinspark-mail.customer-dns-name.com”, “http://mail.customer.com ” or “customer-recruiting.com”. The actual DNS name is is up to customers, but there must be a separate DNS name per instance of ClinSpark with SendGrid connectivity.
This is accomplished after the SendGrid integration is configured as above. This is documented in full on SendGrid’s site, and Foundry Health IQVIA does not support this SendGrid configuration. But in short, to accomplish this the customer must create this domain name on their end and point the DNS MX record to SendGrid. The MX record should look similar to this:
...
Note: You’ll have to configure a second ‘Verification Subdomain’ too with a similar MX and TXT record in order for sendgrid SendGrid to accept that you own the domain, see further instructions.
...
Last, follow the instructions to verify domain ownership by making the required DNS entries. Optionally sendgrid SendGrid will propose to add DNS records for a ‘Verification Subdomain’ (e.g., em1234.mail.customer.com). This ‘Verification Subdomain’ is only used for authentication and verification.
...
You should be set to proceed to the next step. Note: the value for this should be overwritten to https:///emailInbound by the next step. If there is an issue with incoming email, it’s worth checking if this value has been actually overwritten.
Step 6:
...
IQVIA configures each ClinSpark instance with its respective registered SendGrid domain
Foundry Health IQVIA engineering will create required API keys to be used by ClinSpark.
| Note |
|---|
Note to |
...
IQVIA support: Once the proper API key has been configured, you must ensure that the webhooks are configured via the SendGrid API |
...
(screenshot below). |
...
Troubleshooting
Outbound sending works, viewed email notification works, but inbound emails do not show in ClinSpark
...