Microsoft

Vendor ID: microsoft · Maturity: preview · microsoft.com · docs.microsoft.com · Categories: productivity, storage

Microsoft 365 productivity tools and user provisioning from Scrydon into Microsoft Entra ID.

Auth

Products

Calendar scopes: microsoft:calendar requests Calendars.ReadWrite, Calendars.Read.Shared, and Calendars.ReadWrite.Shared. A Microsoft connection created before Calendar or shared-resource support was enabled won't carry these scopes — reconnect the account (an Entra admin may need to re-consent) so calendar calls don't return 403.

Provision users from Scrydon into Entra

Microsoft Entra accepts SCIM bulk payloads through its API-driven inbound provisioning service. It does not expose a generic SCIM /Users target for Scrydon's organization SCIM tokens. These tools use a Microsoft Graph credential and a configured Entra provisioning job. See Microsoft's API overview.

Configure a pilot

1. In Entra, create the API-driven provisioning to Microsoft Entra ID gallery application and configure its provisioning job. Record the enterprise application's object ID (servicePrincipalId) and the job ID. Follow Microsoft's setup guide.
2. Use a tenant-specific Microsoft connection. For unattended uploads, grant application permission SynchronizationData-User.Upload.OwnedBy and ownership of the target application, or SynchronizationData-User.Upload where broader authority is required. Grant AuditLog.Read.All and Directory.Read.All to read provisioning outcomes, then obtain administrator consent. A delegated pilot requests SynchronizationData-User.Upload plus the log permissions; the signed-in administrator also needs the required Entra role.
3. Configure matching and attribute mappings in that job before uploading. Keep externalId stable, for example scrydon:<organizationId>:<userId>. Verify how it matches existing Entra accounts; an email address alone is not a durable anchor. Map active to the intended account enable/disable behavior.
4. Start with a disposable user. Verify create, name change, email change with the same anchor, disable (active: false), and re-enable (active: true). Confirm the resulting Entra object ID stays the same.

Upload and check outcomes

Call microsoft:entra-provisioning:upload-users with at most 50 users:

{
  "servicePrincipalId": "c5b59c64-9085-4f8c-84ea-16137dab08f8",
  "jobId": "API2AAD.your-job-id",
  "users": [{
    "externalId": "scrydon:your-org-id:your-user-id",
    "userName": "pilot@example.com",
    "displayName": "Pilot User",
    "active": true
  }]
}

The output's accepted: true means Graph returned 202 Accepted; processing is still pending. Save the request ID and submission time. Call microsoft:entra-provisioning:list-provisioning-logs with jobId, that user's externalId, and since (the submission time in ISO 8601 UTC). Check provisioningStatusInfo, provisioning steps, and the target identity for each user. Empty logs are not success. For another page, pass the $skiptoken from nextLink as skipToken. Investigate failures before resubmitting; the tools do not retry uploads automatically. Microsoft's bulk upload contract and log reference describe permissions, throttling, and asynchronous results.

These tools submit records supplied by the caller; they do not automatically export Scrydon's directory or schedule ongoing synchronization. Establish one writer per mapped attribute before switching directory ownership. Stop the Azure-to-Scrydon writer for the pilot population before enabling the reverse flow, and retain explicit disable records rather than treating a missing export row as a deletion.

Provisioning does not change Microsoft 365 sign-in. Scrydon's OIDC provider can serve compatible applications, but Microsoft workforce domain federation needs a separately qualified identity-provider protocol and immutable identity mapping. Keep the current Microsoft sign-in path until that cutover is tested.

Shared mailboxes and calendars

A shared mailbox does not sign in to Scrydon. A licensed Microsoft 365 user signs in and acts as the connection's execution account; Exchange then delegates that user access to mailboxes such as hello@example.com.

For a promotable workflow, configure one exact Microsoft connection per workspace environment:

The mailbox address stays the same. OAuth accounts, access tokens, and refresh tokens remain local to each environment and are never promoted.

Configure delegated access

1. In Exchange, grant the execution account Full Access to the shared mailbox. To send with only the shared address visible, also grant Send As. Send on Behalf works, but recipients see the delegate relationship.
2. For shared calendars, grant the execution account the required Exchange calendar delegation.
3. In Entra, grant the delegated Graph scopes required by the product, then reconnect the account if the connection predates these scopes:
   • Outlook: Mail.Read.Shared, Mail.ReadWrite.Shared, Mail.Send.Shared
   • Calendar: Calendars.Read.Shared, Calendars.ReadWrite.Shared
4. Under Settings → Platform → Extensions, create an exact connection for each environment, connect the licensed identity, and designate it as the execution account.
5. Under the workspace's Extensions → Execution credentials, assign that execution account and add the exact mailbox address. Scrydon performs a live Graph read probe before saving the assignment. Microsoft does not expose a complete list of delegated shared mailboxes, so entering the address manually is expected.
6. In the workflow block, select the environment connection by name under Microsoft Account, then choose the assigned address under Mailbox. Choose Execution account default to intentionally use the execution account's own /me mailbox or calendar.

Select an account and mailbox in the canvas

The Outlook and Calendar blocks keep identity and target separate:

• Microsoft Account selects the identity whose Microsoft token authorizes the call.
• Mailbox selects the mailbox or calendar owner that the call targets.

With a personal delegated account, choose My mailbox for /me, or type the exact shared address into the Mailbox field and pick Use <address> — the address is saved immediately. Microsoft Graph does not reliably enumerate every mailbox delegated to a user, so Scrydon then runs a live Graph read probe with that account in the background and shows a warning on the field when access cannot be verified. With an environment or app-only account, the Mailbox list contains only resources assigned centrally to that workspace credential.

The fields come from the extension product's generic resource declaration; they are not Outlook-specific workflow fields. Products with one declared resource use the same account/resource pattern.

Promotion behavior

Blocks store the product and the selected resource, not a Microsoft account ID, and follow the run's identity (see Run As). Promotion keeps hello@example.com unchanged and checks only that the Microsoft product is available in the target environment. It does not check an account, a workspace execution-credential assignment, or Graph access for these blocks: which account is used depends on who the run executes as, and that is only known when the run starts.

Those checks happen at run time instead, as the run's identity. A promotion can therefore succeed while the first run in the target environment stops at the Outlook or Calendar block — for example because the Run As service account has no Microsoft account on that environment's connection, the account is not assigned to the target workspace, or it cannot reach the selected mailbox. Before you deploy, the Promote view shows a readiness warning when the Run As identity has no Microsoft account in the target environment; it does not block the deployment.

A block that still carries a legacy pin to one specific account is checked strictly: the target workspace must have that account assigned under Settings → Workspaces → Execution credentials, and a pinned mailbox must pass a Graph access probe. The Promote view lists these blocks. Switch the block to run-as so it follows the run's identity instead.

When promotion is refused, the Promote view names the target workspace and environment and, for a credential problem, links straight to that workspace's execution credentials.

Sending and Sent Items

For a selected mailbox, Scrydon sends through /users/{mailbox}/sendMail and sets the message from address to that mailbox. With Full Access plus Send As, recipients see the shared mailbox address. Microsoft documents that this endpoint defaults to the from mailbox's Sent Items folder; Exchange administrators can change or duplicate that behavior with the mailbox's sent-item copy settings. See Send Outlook messages from another user and configure shared-mailbox Sent Items.

The Outlook Forward email operation accepts an optional Subject. With no subject, Graph forwards the message directly and preserves its existing subject. With a custom subject, Scrydon creates a forward draft, updates that draft's subject, and sends it. If updating or sending fails, the draft is kept in Outlook Drafts so you can inspect or resend it.

Scrydon can verify Mail or Calendar read access without changing data. There is no non-sending Graph probe for Send As; the definitive test is a real send. If Microsoft returns ErrorSendAsDenied, grant Send As or Send on Behalf and confirm Full Access.

Teams message formatting

The Teams block's write, reply, and update operations expose a Message Format field:

With Adaptive Card, put the card JSON straight into the Message field:

{
  "type": "AdaptiveCard",
  "version": "1.5",
  "body": [
    { "type": "TextBlock", "text": "Deployment Notification", "weight": "Bolder", "size": "Medium" },
    { "type": "TextBlock", "text": "Production build completed successfully.", "wrap": true }
  ],
  "actions": [
    { "type": "Action.OpenUrl", "title": "View Logs", "url": "https://example.com/logs" }
  ]
}

Scrydon wraps this in the shape Graph requires — an application/vnd.microsoft.card.adaptive attachment, referenced by an <attachment> tag in an HTML message body. Selecting Text for card JSON posts the JSON verbatim, which is why a card left on the default format shows up as raw text in Teams.

Triggers

Outlook shared-mailbox new-email triggers use polling with the environment's execution account and selected mailbox. They are not real-time: delegated .Shared permissions cannot create Microsoft Graph change-notification subscriptions for another user's shared mail folders. Polling maintains a separate cursor per workflow trigger. Teams uses its supported webhook behavior. See the Triggers section.

New-file triggers (OneDrive and SharePoint)

OneDrive: New File and SharePoint: New File start one run per file newly created in the watched drive or library. The full reference is File arrival; in short:

• Notification first, poll as the backstop. Scrydon subscribes to Microsoft Graph change notifications for the drive and renews the subscription automatically, so files are usually picked up within seconds. A poll every five minutes catches anything a notification missed.
• New files only. Files already present when the watch arms, later edits, renames, folders and deletions do not fire. A file moved into the watched folder keeps its original creation time and does not fire either.
• Change-tracking resets are not replayed. If Graph invalidates the trigger's change token, the trigger re-arms from that moment; files created while the token was invalid are not delivered.
• One run per file. Bind the trigger's dedupeKey to a create_process_instance dedupe key for one process-flow instance per file.

Shared-resource troubleshooting