Quick Start Guide

🎫 What This Add-in Does

From the Microsoft Outlook reading pane, create a ServiceNow record from the open email in one click. The email subject pre-fills the Short description and the body pre-fills the Description; the record is filed under the ServiceNow account you sign in with. Optionally, AI can draft a clearer title from the subject and a short summary with action items from the body — you review and edit before creating. Set urgency, impact, category, assignment group, and assignee before you create. The original email is attached to the record as an .eml file, along with the email's own file attachments.

🔑 Roles the connecting user needs

The user (or, for Basic auth, the integration user) needs write on the target table (e.g. itil for incident), create on sys_attachment, and read on sys_user, sys_user_group, and sys_choice. If sys_choice is restricted, the add-in falls back to built-in choice lists and still works.

🔐 Does your instance use SSO with Microsoft Entra ID (or another identity provider)?

Nothing in Part 1 changes, and nothing is configured in Entra ID for ServiceNow sign-in. The OAuth Application Registry record is configured exactly as above — it has no identity-provider field — and the add-in never contacts Microsoft Entra to sign users in to ServiceNow. Single sign-on is handled entirely by your instance's own login: when the sign-in window opens your instance's authorization page and finds no session, ServiceNow's Multi-Provider SSO redirects that window to your identity provider — the same Identity Provider record on the instance, and the same ServiceNow enterprise application in Entra ID, that your users already rely on for browser sign-in. After the identity provider signs the user in, ServiceNow creates the session, shows its Allow page, and hands an authorization code back to the add-in. The add-in only ever holds tokens issued by your instance.

Separately, the add-in has a Microsoft Entra application of its own ("Email to ServiceNow", published by Innova Apps), used only for its subscription check and organization defaults. If your tenant doesn't let users consent to applications, an Entra admin may be asked to approve its basic sign-in and profile permissions. That approval is unrelated to ServiceNow and to your SSO setup.

Worth knowing for SSO instances:

• In classic Outlook for Windows and Outlook for Mac, the sign-in window is a separate browser session, so an existing sign-in in your web browser does not carry over. If your identity provider is not set as the Auto Redirect IdP, users may first see ServiceNow's own login page and click "Use external login". Outlook on the web opens a normal browser popup and reuses the browser's sessions. New Outlook for Windows also opens a popup, but from the Outlook app rather than your web browser, so treat it like classic Outlook and include it in your testing.
• ServiceNow still shows its Allow/Deny page after the SSO sign-in.
• Entra Conditional Access policies that require a compliant, hybrid-joined, or managed device may block sign-in in classic Outlook for Windows, Outlook for Mac, and possibly new Outlook for Windows, because those sign-in windows may not be able to prove device state. MFA-only policies work, and Outlook on the web inherits the browser's device identity and usually passes. Test with a pilot user before rolling out.
• OAuth needs the standard https://<instance>.service-now.com URL. If your instance uses a custom domain, users enter the standard URL, which ServiceNow keeps working alongside the custom one. That works if single sign-on already works when the standard URL is opened in a browser; if your SSO is set up only for the custom domain, use the Basic auth fallback below.
• If the Microsoft sign-in succeeds but ServiceNow reports that the user was not found, the Identity Provider record's User Field does not match the user's record — an SSO configuration matter on the instance, not an add-in setting.

🔒 Basic auth fallback

If you can't use OAuth, the add-in also supports Basic authentication with a dedicated ServiceNow integration user that has "Web service access only" checked. That user needs a password set locally on the instance — accounts provisioned through SSO usually have none — and it cannot be used for the interactive OAuth sign-in. In the add-in, Basic auth is the Username & password option. OAuth with PKCE is recommended because authentication runs against your own instance, so your company's SSO and MFA apply.

⏱️ Optional: fewer reconnects

The same Application Registry record has a Refresh Token Lifespan field, in seconds, defaulting to 8640000 (100 days) — that's how often users are asked to click Connect again. Raise it (for example 31536000 for a year) if you'd rather they never had to. The trade-off is honest and worth weighing: a longer-lived refresh token is a longer-lived credential sitting in the user's browser storage, so check it against your own credential-lifetime policy. You can always revoke a user's tokens immediately from System OAuth → Manage Tokens.

💡 Note

Some organizations restrict self-installation of add-ins. If you don't see the option to add apps, contact your IT administrator or use Option B.

🏢 Admin Benefit

Admin deployment automatically pushes the add-in to all targeted users. No action required on their part.

🔐 Authentication & Storage

OAuth 2.0 with PKCE runs against your own ServiceNow instance, so your company's SSO and MFA apply. Connection settings and tokens are stored only in the task pane's browser localStorage on the add-in origin; nothing is sent to Innova-Apps. A stateless OAuth token broker only relays the token exchange to your instance and persists nothing. If the add-in asked you to sign in to Microsoft when it first opened, that was its subscription check for your Microsoft 365 organization — a separate step that does not sign you in to ServiceNow. (If your admin set up Basic auth instead, enter the integration user's credentials.)

📧 Contact Support

For issues, questions, or feature requests:
Email: support@innovaapps.ai · Support page