Onboarding Options for Emailgistics
There are two ways to onboard Emailgistics. This technote will provide an overview of the two options and highlight why you might choose one method over the other. The two options are very similar in that the result is always the provisioning of an encrypted Microsoft Graph Access Token granting us specific API privileges to operate on the shared mailbox you are onboarding.
The granted token lets Emailgistics view and manipulate messages in the shared mailboxes you have onboarded and get basic information about users.
We do not have access to mail outside of the scope of the onboarded mailboxes (e.g., we can’t see into personal mailboxes).
The specific Graph API privileges we require varies slightly between the two onboarding methods.
-
This is the method most Emailgistics customers use to onboard as it is slightly easier. It does require that the Exchange Admin doing the onboard assign a password to the shared mailbox and use it to assign Microsoft Graph privileges to Emailgistics during the onboard.
Emailgistics never sees or stores the mailbox password. This is the same method that users use to grant permissions to applications that access their personal mailboxes (CRM solutions like Salesforce use this method).
Some companies have policies that prefer their shared mailboxes not have passwords assigned to them. In this case, Method 2 is the method you will use.
Method 1 will add Emailgistics as an Enterprise Application in your Azure Active Directory where you can see the Graph privileges that you have authorized for the application. You can also revoke the token at anytime and remove our access completely.See our “Onboarding Instructions – Mailbox Authentication Method” document for a step-by-step guide on using this onboarding method.
-
This method does not require that a shared mailbox be assigned a password. Instead, you will create an App Registration for Emailgistics in Active Directory. Once you create this App Registration, you will generate a unique client secret that you will share with us during the onboard. The combination of the appID and client secret is what Emailgistics uses to obtain a required Graph access token that you have authorized. Client Secrets are not the same as passwords, and are the standard way of granting tokenized API access.
Additionally, during the onboard, we will guide you through the steps of limiting the registered app to work only with email from the shared mailboxes you want to onboard and to assign only the specific API permissions we require. We limit the scope of our access to the minimum we need.
Another advantage this method offers is it that it provides more flexibility in dealing with Graph API throttling limits. While this generally is not a problem, larger enterprises with very high mail volumes in their team mailboxes can hit these limits. With this onboarding method, we can choose to add multiple app registrations, and group onboarded mailboxes in these apps intelligently to ensure we don’t experience any API throttling.Microsoft limits app registration expiry to 2 years, after which a new client secret must be generated and shared with us so that Emailgistics can continue to generate the required Graph access token. Emailgistics will automatically notify System Admins 30 days before the expiration date.
See our “Onboarding Instructions – App Registration Method” document for a step-by-step guide on using this onboarding method.
Choosing an Option
Both options result in the same outcome and are similar in many ways. Method 2 is the only option if you do not want to create a password for the shared mailbox. Larger organization may opt for Method 2 to accommodate higher mail volumes. An Emailgistics onboarding specialist will work with you to help determine the best method to follow.