Add-in, task pane and per-environment manifests
Outlook integration
The Outlook add-in opens Xedul in the mail client's task pane, on desktop and on the web. The flow matches Gmail: you start from a message and end with a task linked to the correct client and case.
What to know first
The Outlook integration is distributed through a manifest: a file telling Outlook where to find Xedul and how to display it. Separate manifests exist per environment, with distinct identifiers, so development, staging and production can coexist on the same mailbox.
| Manifest | Points to |
|---|---|
| Develop | Development environment |
| Staging | Test environment |
| Production | `https://xedul.com` |
| Local | Custom origin, for tunnel-based testing |
The distinct identifiers are why several environments can be installed side by side without overwriting each other. It's useful during testing and doesn't cause confusion, because the pane reflects the environment it is connected to.
Installing in production
- Open the Outlook sideload page:
https://aka.ms/olksideload. - Select the production manifest.
- Confirm the installation.
- Open a message: the Xedul command appears among the available actions.
Using it
- Open the message you want to work in Outlook.
- Run the Xedul command to prepare the task.
- Sign in to Xedul directly in the task pane, if you haven't already.
- Fill in the form: client, case, assignee, priority, due date.
- Confirm. Outlook stores the draft and opens Xedul on the tasks page with the data already present.
- If the browser asks for authentication, sign in with the same Xedul account.
The task pane and the browser are two distinct contexts. If you sign in inside the pane but the browser has no valid session, you'll be asked to sign in a second time: that's expected, not an error.
Local testing with a tunnel
Outlook requires a public HTTPS origin: it cannot load the pane from localhost. To test against a local instance you need to expose the application through a tunnel.
- Start the Xedul application locally.
- Start the tunnel pointing at the application's local port.
- Copy the tunnel's HTTPS origin, without a trailing slash.
- Render the manifests for that origin using the render script included in the repository.
- Open the tunnel address once in a browser and accept any warning page.
- Sideload the local manifest from
https://aka.ms/olksideload. - Open a message and run the Xedul command.
Re-rendering the manifests
The render script must be run every time the application's public address changes. It accepts the origin as a parameter, or reads it from an environment variable; with neither, it uses the default address from the central configuration.
Each run also updates the three fixed manifests — develop, staging and production — and aligns the Gmail integration configuration, so every integration points at the same environment.
Free tunnel URLs change on every restart. If the pane suddenly stops loading during a test session, the first thing to check is whether the tunnel is still on the same address.
The complete flow
- The message arrives in the practice's mailbox.
- The Xedul pane opens inside Outlook.
- You fill in the context: client, case, priority, due date.
- Outlook stores the draft and opens Xedul with the data already present.
- You confirm, and the task is created linked in the right place.
Differences from Gmail
| Gmail | Outlook | |
|---|---|---|
| Entry point | Button in the page, or side panel | Task pane |
| Distribution | Browser extension or Workspace add-on | Sideloaded or distributed manifest |
| Side-by-side environments | One configuration at a time | Develop, staging and production together |
| Network requirement | Public origin for the Workspace add-on | Public HTTPS origin always |
The result is identical: an Xedul task linked to client and case, generated from a message.
Troubleshooting
| Symptom | Likely cause | What to do |
|---|---|---|
| The Xedul command doesn't appear | Manifest not loaded, or Outlook not refreshed | Reload the manifest and restart Outlook |
| The pane stays blank | Origin unreachable or not HTTPS | Check the tunnel and re-render the manifests |
| Sign-in requested twice | Session in the pane but not in the browser | Sign in the browser too: this is expected |
| The pane points at the wrong environment | A different environment's manifest is installed | Check which manifest is active and remove the ones you don't need |
| Error after changing address | Manifests not re-rendered | Run the render script again with the new origin |
| Tunnel warning page | Origin never opened in the browser | Open the address once and accept the warning |