This article will provide you with an overview of email groups and aliases in Ironclad.
You may want to trigger an email to a group of users, not merely one member of a group. Or you may want the initial assignment of an activity such as an approval request to go to all users in a group, rather than just one.
Ironclad does not currently support this kind of notification directly because all activities in Ironclad, such as approvals or signatures, are ultimately performed by an individual account.
A common approach—and the one we recommend as best practice—is to set up an email alias, such as legal-approvers@[your company's domain] or finance-review-queue@[your company's domain], that redirects to multiple users. That email alias would then be associated with its own account in Ironclad in order to be assigned to appropriate roles or used in email configurations. Once the email is sent out to the distribution list, an individual user would “pick up” the task by navigating into Ironclad and assigning their own user to that role. In most cases, it makes sense to make this Ironclad “user” the default user in the corresponding Ironclad group so that references to that group use the email alias as the assignee or recipient by default.
Prerequisites
Before proceeding further, make sure that:
- Your group alias exists within your email system.
- Your group alias has members/recipients.
- Your group alias can receive emails from external senders. It must not accept only internal emails from your organization’s domain(s).
You will not be able to proceed and will encounter errors if the email address is not valid yet—that is, it has not been created or does not actually result in any humans receiving an email.
Use Aliases in Ironclad
- If you have not done so already, create the group in your email system.
- If you created the alias account in a system other than your email system or ESP, such as Active Directory, IIQ, or Okta, be sure that you push the alias account to your email system or ESP before proceeding.
- Add at least one member/recipient to the group.
- Ensure that the group can receive emails from external senders.
- If you host email on Google, be sure that Who can post is set to Anyone on the web for each group alias you will use with Ironclad.
- If you host email in Exchange, make sure that both Senders inside and outside of my organization can send messages to each group alias you will use with Ironclad.
- If you use a platform other than Google or Exchange, be sure you follow that platform’s instructions on this point.
- We strongly encourage you to test this at this point, such as by having a user send an email from a personal account not on your organization’s domain (Gmail, Yahoo!, etc.) to the email alias address and verifying that it is received by the alias recipients.
- Create a user account in Ironclad for the alias.
- This can be done via your SSO/SCIM platform if (1) you have integrated it with Ironclad and (2) your organization allows creation of alias “users” in that way.
- It can also be performed directly in Ironclad, via Company Settings > Users and Groups.
NOTE
If, for some reason, you have added the alias to more than one Ironclad instance on the same stack—that is, more than one “company” on, for example, demo.ironcladapp.com—then a user would need to log in as the alias in order to accept the invitation. That can be confusing and tricky for users. You may find it easier to add users to the instance directly using the Create a User I ronclad API endpoint, which you can do directly from the link.
- If the alias should be the default user for any groups, go to each group in question in Ironclad (Company Settings > Users and Groups) and make that user the default user for that group.
Best Practices for Administering Email Aliases
- Begin the process of setting up and testing email aliases immediately upon beginning an Ironclad implementation. While following all of the instructions above may take only a few moments, we often find that customers need to go through significant internal processes and approvals before creating aliases, before creating Ironclad accounts associated with aliases, or at various other points along the way. It is critically important that you begin this process early if you intend to use aliases in connection with Ironclad.
- Be sure to create and test email aliases before attempting to use them in connection with Ironclad.
- If you are creating new aliases instead of using existing ones, use a memorable and unambiguous name for your aliases, ideally one clearly identified with a corresponding group in Ironclad. For example, if you have a Finance group that will approve workflows in Ironclad and do not already have an email alias that you will use for this purpose, good alias names might include:
- finance.approvers@yourcompany.com,
- finance.contract.approvers@yourcompany.com,
- finance.group@yourcompany.com,
- finance.group.alias@yourcompany.com, or simply
- finance@yourcompany.com (but note that this last option may be more likely to attract spam from the internet at large if there are no restrictions on senders that can send mail to it).
- Be sure that your alias can receive email from anywhere (that is, from senders on any domain). If you choose to impose domain-based restrictions, please be sure that at least the following are allowed:
- Your company’s domain name
- *.ironcladapp.com (ironcladapp.com and all subdomains thereof)
- Recommended: the domain(s) associated with your eSignature provider(s), e.g., sign.ironcladapp.com, docusign.com, etc.
- Create and test the Ironclad accounts for your aliases well in advance of your go-live or first date of planned use. Be sure that the accounts are activated (emails verified), can be assigned to appropriate roles, are receiving Ironclad notifications, and are otherwise working as expected.
- If you encounter any issues or questions, please reach out to your Ironclad implementation team (if applicable) or submit a request with our Support team if you are not working with our Professional Services teams) as soon as possible for help.