Outlook Add-in: Routed Key Behaviors

Prev Next

Overview

This article covers behaviors specific to routed Outlook Add-in deployments that admins should understand before and after launch. These are not bugs or errors — they are expected behaviors that require intentional configuration to handle correctly. For issues with the add-in not deploying or signatures not appearing, see the Outlook Add-in Troubleshooting Guide.

This article applies to customers using the plaintext block or stamping deployment modes. For visual preview-specific behaviors, see Outlook Add-in Visual Preview: Capabilities and Tradeoffs.

Field edits with stamping

When the add-in is configured to allow field edits alongside stamping, the plaintext block in the stamping mail flow rule must be adjusted. Any field that users can edit in the add-in pane should be excluded from the plaintext block in the rule — otherwise the user's edited value will be overwritten by the value in the rule when Opensense processes the email server-side.

The default stamping rule Opensense deploys includes the following fields:

[[#]]
name: %%DisplayName%%
title:  %%Title%%
phone:  %%Phone%%
email:  %%Email%%
mobile: %%MobileNumber%%
[[#]]

If any of these fields are unlocked for user editing in the add-in, remove the corresponding line from the rule. For example, if users can edit their title in the add-in pane, remove title: %%Title%% from the rule so their input is not overwritten server-side.

Shared accounts and alias permissions

Any account linked to a user's primary account automatically inherits add-in permissions. This means the add-in functions correctly when a user switches the From address to a linked alias — no additional configuration is required for the add-in itself to activate.

There is one exception: if the shared mailbox is accessed directly rather than linked through a primary account, it must be explicitly added to the add-in's deployment scope in Microsoft 365 Admin Center. Accessing the mailbox directly does not inherit permissions from another account.

Controlling which signature appears on From-switched emails

The From Switching setting in Opensense Domain Settings controls whether the add-in looks up the switched account's own data and signature template, or keeps the primary user's signature regardless of which From address is selected.

  • From Switching off: The primary user's signature stays in place no matter which From address is selected. This is the simplest approach for organizations that want employees to send with their personal signature from all accounts they have access to.

  • From Switching on: When a user switches the From address, the add-in looks to the switched account for its data and signature template. Use this when shared inboxes or aliases have their own distinct signature requirements — for example, a generic support or team inbox that should display shared branding rather than an individual's details.

For a full breakdown of From Switching behavior, including Merge Fields and shared inbox scenarios, see Outlook Add-in Domain Settings with Scenarios and Best Practices.

Sending As vs. Sending on Behalf

Send As and Send on Behalf are two distinct Microsoft 365 permission types that affect how Opensense processes the sender identity when routing email. The behavior differs between the two and can affect which signature is applied.

For a full explanation of how these permissions interact with Opensense routing, see Understanding Send As and Send on Behalf in Outlook.

Switching to domains not configured in Opensense

If a user switches their From address to a domain that is not configured within Opensense, the add-in may retain and display the previous signature value rather than clearing it. To prevent this, enable Remove Signature for Unknown Domain in the add-in's Domain Settings. This clears the signature when the user switches to a domain Opensense does not recognize.

Ensure all domains the organization uses are listed under Internal Domains in the Opensense portal. If your organization uses multiple primary domains, each domain must be referenced in the other's domain settings to ensure Opensense recognizes them correctly.

Add-in pane signature preview

For both stamping and plaintext block deployments, the add-in pane displays a non-clickable preview of the signature recipients will receive after server-side transformation. This requires no additional configuration — it is built into the add-in's behavior for both routed modes.

For plaintext block deployments, the compose window contains the [[#]] token. The add-in pane is where users see the rendered preview.

For stamping deployments, nothing is inserted into the compose window. The add-in pane preview is the only place users can confirm a signature is active and see what it looks like.

The preview is read-only. Users cannot interact with or edit it.

Opensense Outlook Add-in: Plain Text Preview

Multiple signature selection

The add-in supports multiple signatures per user, allowing employees to switch between assigned signatures directly from the add-in pane. This requires Multiple Signatures to be enabled in Domain Settings and signatures to be properly assigned through routing.

For configuration details and priority behavior, see Outlook Add-in Multi-Signature Selector.

Related articles