Stargate

❓ Help & User Guide

Signing in

There is no separate portal password — authentication is your organization's Microsoft sign-in, and access is granted by WCM ahead of time. The whole process takes a few seconds:

Step by step:

1. Open the portal URL (bookmark it after the first visit) — you'll see the landing page above. Click Sign in with Microsoft.
2. Microsoft's familiar sign-in window opens. Enter your work email address and continue with your normal password and MFA prompt — exactly as you'd sign in to any of your organization's Microsoft services. The portal never sees your password.
3. After Microsoft confirms who you are, the portal checks its own registry — is this account authorized, and for which clients? A brief "Verifying…" spinner shows while that happens.
4. You land on the client list, showing the client organizations your account may act for — see Selecting a client.

If sign-in doesn't complete: two different messages can appear after Microsoft accepts your credentials — "Account isn't authorized" (your account isn't registered for the portal) or "Account locked" (too many failed attempts). Both are explained under Sign-in refused or locked.

Selecting a client

After sign-in you land on the client list — the client organizations your account is authorized to act for. Most people see exactly one; accounts that work with several clients see a card for each.

Step by step:

1. Each card shows the client's name and its short code (the code you'll also see in run names and in emails from WCM — e.g. ACME for Acme Corp).
2. Click a card to open the client. The tab row appears — Upload, Download, Job Status, History, Archive, Connect AI — and every one of those tabs works against this client only: its connections, its files, its history.
3. To work with a different client, click ← All clients (top-left) and pick another card. Nothing is lost by switching — jobs already started keep running and will be right where you left them.

Things worth knowing:

• A client you expect is missing — your account simply isn't assigned to it yet. Ask your WCM administrator; once assigned, it appears on your next sign-in.
• Only one card? That's the normal case — most accounts are authorized for a single client and can head straight in.
• Your list is yours — it reflects your account's authorizations, so a colleague's list may differ from what you see here.

Portal layout & tabs

Once a client is open, the screen has four fixed regions — everything you do happens in the content area under the tab row:

1. Top bar — always visible: the portal name, who's signed in, and Sign out.
2. ← All clients — returns to the client list to switch clients; see Selecting a client.
3. Tab row — the client's name and code, then one tab per feature. The highlighted tab is the one you're on.
4. Content area — the selected tab's controls and tables. Switching tabs never cancels anything: a send started on Upload keeps running while you look at History.

What each tab is for:

Time zones & timestamps

Every timestamp in the portal — run start times, durations, archive dates, log steps — is shown in one configured time zone, set by your WCM administrator. The column header always tells you which zone you're looking at:

How it works:

• One zone for everyone. The zone is a system-wide setting chosen by your administrator — it is not your browser's or computer's local zone. That means you and a colleague in a different country see identical times for the same run, so there's never confusion about when something happened.
• The header is the label. Columns like Started (History) and Date Archived (Archive) show the zone abbreviation — e.g. (PDT) or (UTC) — so you never have to guess.
• Stored safely, displayed conveniently. Underneath, every time is recorded in UTC and only converted for display. If the administrator changes the zone, all records — past and future — simply re-display in the new zone on your next sign-in or page reload. Nothing is rewritten.

Choosing the destination connection

A connection is a destination WCM has set up for your client — an SFTP server, a SharePoint library, or an email delivery. Your first decision on the Upload tab is which one the files should go to:

Step by step:

1. Open the dropdown and pick the destination. If your client has only one connection it's already selected — most people never need to touch this.
2. With several connections, the list shows every destination WCM enabled for portal use — the image above shows one of each type: an SFTP server, a SharePoint library, and an email delivery. Sending works identically whichever you pick; only where the files land differs.
3. Glance at the banner above the drop zone before sending — it always states exactly where files will go.

Things worth knowing:

• The connections you see are the ones WCM has enabled for portal use — the same client may have other connections reserved for automated systems that don't appear here.
• Whether a connection can encrypt or decrypt depends on the keys WCM attached to it — see How keys work. The encryption options tell you if a key is missing.
• If the dropdown is empty you'll see a yellow warning instead — the client has no portal-enabled connections yet. See A connection is missing.

Adding files

Add files by dragging them in or browsing for them, then review the list before sending:

Step by step:

1. Drag & drop files onto the zone (it highlights when you're over it), or click Browse files… and select them — multi-select works, and there's no size limit.
2. Each file appears as a row showing its name and size, with a running count and total above the list.
3. Change your mind? Remove a single file with its ✕, or Clear all to empty the list.

Encrypting or decrypting on send

Files can be protected (or un-protected) in transit, as part of the send itself — no separate tool needed. Once files are listed, the encryption bar appears:

The three choices (bulk bar, or per file):

• No encryption/decryption — files are sent exactly as they are.
• 🔒 Encrypt all files — each file is encrypted with the connection's public key and delivered as name.pgp (or name.p7m); only the destination's key holder can open it. See Encrypting a file.
• 🔓 Decrypt all files — for sending the plaintext of files you hold encrypted: the portal decrypts each file with the connection's private key as it sends. See Decrypting a file.

How the bulk bar and the per-file column interact:

1. The bulk choice is sticky — it applies to the files already listed and any you add afterwards.
2. The per-file column then overrides individual rows — e.g. encrypt everything except a plain-text cover note, as shown in image ② above.

Sending & watching progress

With the connection chosen and files listed, one click starts the delivery:

What happens after you click Send:

1. The files upload to WCM's secure staging storage, and the portal switches to Job Status automatically so you can watch.
2. The transfer engine delivers each file to the destination — applying encryption if you chose it.
3. When the run finishes it clears from Job Status; the complete record (with its step-by-step log) appears on History, and the delivered files land on the Archive tab.

Large files & background delivery

There's no size limit on uploads — but very large files are handled differently behind the scenes, and it helps to know what that looks like:

How it works:

1. Your browser uploads the file to WCM's staging storage as usual — this part needs your browser open.
2. Files over the size threshold are then handed to a background delivery queue instead of being delivered inside your browser session. The run shows as Queued, then Running.
3. The engine completes the delivery on its own — you can close the browser once staging has finished. The result is waiting on History when you come back.

Choosing the source connection

The Download tab pulls files from a source — a remote SFTP server, a SharePoint library, or a monitored mailbox. Start by picking where to look:

Step by step:

1. Pick the connection from the dropdown — the same list of destinations you see on Upload, because most connections work in both directions.
2. For SFTP connections you can type a directory path (for example /outbound) — leave it empty to list the connection's default directory. The banner shows which directory will be listed.
3. SharePoint connections need no path — they list their configured library folder. Mailbox connections replace the path with a look-back window — see Mailbox connections & look-back.

Mailbox connections & look-back

A mailbox connection is a monitored email inbox: partners email files in as attachments, and you collect them here — no server or credentials on their side needed. When you pick one, the directory path is replaced by a look-back control:

How it works:

1. Pick the mailbox connection — the Look back N days control appears in place of the path box.
2. By default the connection's configured window is used and the number is greyed out — most of the time you just click Connect & list and see the recent attachments.
3. Need something older? Tick Override and set your own window — up to 3 years (1095 days).

Things worth knowing:

• Only messages matching what WCM configured for the connection (the expected sender and/or subject) are considered — unrelated mail in the inbox never shows up.
• What you get is the attachments, listed like files. Attachments that arrive encrypted can be decrypted as you download them — see Decrypt or encrypt on download.
• A longer look-back scans more mail and takes a little longer — use the default unless you're hunting for something specific.

Decrypt or encrypt on download

Before listing files, choose what happens to the bytes as they're downloaded — the dropdown sits just under the connection picker:

The three choices:

• Download as-is — exactly what's on the remote server or mailbox, byte for byte.
• 🔓 Decrypt on download — for files that arrive encrypted (report.csv.pgp): the connection's private key decrypts in transit and you receive the readable report.csv. See Decrypting a file.
• 🔒 Encrypt on download — the reverse: a plaintext file on the remote lands on your disk protected (report.csv.pgp), useful when the readable version shouldn't touch your machine. See Encrypting a file.

Listing & downloading files

With the source and options set, connect and pick what you need:

Step by step:

1. Click Connect & list remote files. A brief spinner shows while the engine connects to the server (or scans the mailbox) — the connection happens from WCM's side, never directly from your browser to the partner.
2. The listing appears with each file's name, size, and date. Click ⬇ Download on the ones you need — your decrypt/encrypt choice is applied to each file as it comes down.
3. Every download lands in your browser's normal download location and is recorded on History.

Watching running jobs

Job Status is the live view: every job currently running for this client, whoever started it — you, a schedule, a partner system, or an AI assistant:

How to read it:

• Job — what's being transferred and where to; Category — which channel started it (see Run categories for every badge).
• Progress and Elapsed update automatically while the tab is open — no need to refresh anything.
• When a job finishes it clears from this tab; the complete record appears on History a moment later, with its step-by-step log.

Server-side jobs appearing

Not everything that moves files starts in your browser — schedules fire, partner systems call the API, AI assistants act on someone's behalf. When one of those completes while you have the client open, it surfaces here briefly so the activity doesn't slip past you:

What to expect:

• The run pops in already in its final state (Completed, Failed…) — server-side transfers finish on the engine, so there's no live bar to watch, just the outcome.
• It lingers for a few seconds, then clears; the permanent record is on History with everything else.
• This only happens while you have the client open — jobs that ran overnight don't queue up waiting for you; you'll find them on History (filter by category to see just the automated ones).

Filtering & searching runs

History holds every run that ever executed for this client, so the filter bar is how you find the one you're after:

Each control:

• 🔎 Search by name — narrows the table as you type; matches the job/run name.
• Category — show only one channel's runs (see Run categories): just your uploads, just scheduled runs, just API traffic…
• Status — e.g. only Failed runs when you're checking whether anything needs attention (see Run statuses).
• From / To — date range, yyyy-mm-dd. Combine with search to find "that file we sent in June".
• Page size — rows per page; ↻ Refresh pulls the newest runs from the server (the table also refreshes when you open the tab).

Run categories

Every run carries a category badge saying which channel started it, and a User column saying exactly who or what that was:

The five categories:

Run statuses

The Status column tells you how each run ended — or that it hasn't yet. The colors are consistent everywhere in the portal:

Every status:

Reading a run's log

Every run keeps a step-by-step record of what actually happened. Click Log on any History row to open it:

What the timeline tells you:

• Every step in order — connect, each file's delivery, archiving — with a timestamp and a ✔/✖ dot.
• Failures include the exact error message from the attempt (like the quota error above), which usually says precisely what to fix — and whose side it's on.
• For a Partial run, the timeline is how you see which files made it and which didn't.

Archive folders

Every delivered file is retained, organized by the channel that sent it. The folder dropdown switches between them:

The folders:

• User — download-upload — files sent from this portal. The only folder with actions: Re-Send and Encrypt/Decrypt.
• API — api — files sent by systems using an API key. View-only: you can look and download, not act.
• Managed Identity — mi — files sent by Azure apps. View-only as well.

The separation is deliberate: it keeps each channel's activity distinct, so "what did the portal send" and "what did the partner's system send" are never mixed together.

Re-Sending a delivered file

A partner lost a file, or needs last month's delivery again? Nothing needs re-uploading — the archived copy can be pushed again as-is:

Step by step:

1. Open the User — download-upload folder (re-send only works there — it's the folder this portal owns).
2. Tick one or more files and click Re-Send to client →.
3. Progress shows on Job Status; the re-send is recorded on History as a new run, and the destination receives the file exactly as it was originally delivered.

Encrypt / decrypt in place

Archived files can be transformed where they sit — no transfer involved. Select files in the User folder and the crypto buttons appear next to Re-Send:

How it behaves:

• 🔒 Encrypt / 🔓 Decrypt appear only when the chosen connection holds the matching key — see How keys work.
• The result is written beside the original; the original is never overwritten. If a result file with that name already exists, the operation refuses rather than replacing it.
• Nothing leaves the archive — this is a local transformation. Sending is a separate, deliberate step.

Searching & paging

Archives grow over time, so each folder has the same finding tools as History:

• 🔎 Search narrows by file name as you type — it searches the folder you're in, so switch folders to look elsewhere.
• Date Archived is sortable (click the header to flip) and shown in the configured time zone.
• Page size and ↻ Refresh work exactly as on History.

How keys work

Keys live on the connection and are managed by WCM — you never handle key material. Each connection has two independent key slots:

The two slots in detail:

Neither key implies the other: a connection may encrypt only, decrypt only, both, or neither. The file format is chosen automatically from the key type — a PGP key produces name.pgp, an X.509 certificate produces S/MIME name.p7m.

Encrypting a file

Encrypting locks a file with the connection's public key so only the destination's key holder can open it:

Where you can do it — three places, all using the same key:

• Upload — bulk bar or per-file toggle; the destination receives name.pgp / name.p7m.
• Download — "🔒 Encrypt on download" protects the file before it reaches you.
• Archive — encrypt in place, writing the encrypted copy beside the original.

Decrypting a file

Decrypting is the mirror image: the connection's private key — which never leaves WCM's vault — unlocks a protected file back into its readable form:

Where you can do it — the same three places:

• Upload — send the plaintext of a file you hold encrypted ("decrypt on send").
• Download / Mailbox — receive the plaintext of files that arrive encrypted.
• Archive — decrypt in place; the recognized encrypted extensions (.pgp, .gpg, .asc, .p7m, .smime) are stripped from the result's name.

Common encryption errors

Encryption errors are designed to be loud and specific — the portal never silently skips protection. A typical one looks like this:

What each message means:

What the AI connector is

Stargate is also an MCP server — a standard interface AI assistants use to work with external systems. Connect your assistant and file transfers become something you can simply ask for:

The key idea — it acts as you:

• It signs in with your Microsoft account, sees only your clients, and obeys the same permissions as this portal.
• Every action lands on History with the MCP Based badge and your email as the user — indistinguishable from your own actions in accountability terms.
• It never sees passwords or connection credentials — those stay in WCM's vault and are used only by the engine.

Connecting your assistant

Everything you need lives on the portal's 🤖 Connect AI tab — most importantly the server URL:

Add it to your assistant:

• Claude Desktop / web: Settings → Connectors → Add custom connector → paste the Server URL.
• Claude Code: claude mcp add --transport http wcm-sftp <server URL>
• Other MCP clients: add an HTTP (streamable) server with that URL; choose OAuth if asked, and leave client id/secret blank — registration is automatic.

Signing in (OAuth)

The first time your assistant talks to Stargate, it hands the sign-in to your browser — the same Microsoft prompt you know from the portal:

How it works:

1. The first tool call opens your browser. Sign in with the same Microsoft account you use for this portal — password and MFA happen with Microsoft, never with the assistant.
2. The assistant receives a token and refreshes it silently from then on — you won't be asked again for a long time.

Requirements — both must be true, or tool calls will say so:

• You're a registered portal user (you can sign in to this portal).
• Your client has AI access enabled — if a tool call reports MCP access is disabled, ask WCM to enable it.

What the assistant can do

Once connected, plain requests translate into Stargate operations — a good first ask is read-only:

The full toolbox:

WCM can limit which tools are available to your client; a missing tool is policy, not a bug.

The duplicate-send guard

Sending the same file to the same connection twice within 15 minutes is refused — and that refusal is a feature. Here's the guard working as intended:

Why this exists: the usual reason anyone re-sends is a first attempt that looked failed — and with large transfers, the request can time out while the delivery carries on and completes. Without the guard, that pattern produces duplicate files on the partner's server.

The right sequence when a send looks failed:

1. Have the assistant check list_history / get_run_status for the run.
2. If it completed — done; nothing to re-send.
3. Only if History confirms it did not arrive should it retry — the tools accept force for exactly that case.

Setup guide to download (.md)

Rather than configuring by hand, you can hand the setup to your assistant: download this Markdown guide and give it to your Claude (or any MCP-capable assistant). It contains everything the assistant needs to connect itself to Stargate and verify the connection works.

How to use it:

1. Click ⬇ Download — you get a plain-text Markdown file, readable in any editor.
2. Give it to your assistant: attach it in Claude Desktop/web, or in Claude Code just say "read stargate-mcp-setup.md and connect to Stargate".
3. The assistant follows the guide — adds the server, triggers the browser sign-in, and runs the verification ask. You only touch the Microsoft sign-in prompt.

What's inside — the guide's sections, so you know what your assistant is following:

API keys & IP allowlist

The API channel lets your systems — scripts, schedulers, integration platforms — exchange files without a person in the loop. Access rests on two things WCM sets up for you:

How it works:

• WCM issues your system a key (it looks like sk_…) and records the IP addresses it may call from. Both must match — a valid key from an unlisted address is refused.
• The key is shown once and stored hashed on WCM's side — put it straight into your secret manager; nobody can retrieve it for you later, only issue a new one.
• Every request carries it in the X-Api-Key header — see Available commands.
• Contact WCM to issue, rotate, or revoke a key — changes take effect within about a minute.

Available commands

The API mirrors this portal — everything a person can do on these tabs, a system can do with one HTTP call. The first call to make is always /v1/me:

The full command reference. Each command below has its parameters and a ready-to-run example. Pick your format once — cURL, REST (raw HTTP), or PowerShell — and every example on the page switches together. Replace <connId>, <runId>, and file names with your own values.

The typical send sequence: POST /v1/files (stage the file) → POST /v1/transfer (push it to a connection) → check the result. Encryption works exactly as in the portal — pass "crypto": "encrypt" (or "decrypt") on the transfer.

Large transfers: pass "async": true on /v1/transfer — you get 202 + a runId immediately; poll /v1/runs/{runId} for the outcome instead of holding the request open.

Auditing & the API folder

Nothing your systems do via the API is invisible — it all lands in the same portal views you already use:

Where API activity shows up:

• History — every upload and download appears with the API Based badge and the key's prefix (e.g. sk_acme) as the user, so you can always tell which system did what. Filter Category to "API Based" to see only machine traffic.
• Job Status — in-flight API transfers show live like any other job.
• Archive — API-sent files are retained in their own api folder (view-only in the portal), kept separate from files people sent.

What Managed Identity access is

If your integration runs in Azure (Function App, Web App, VM…), it can authenticate as itself — using the identity Azure manages for the app — instead of holding an API key:

Why teams choose it over an API key:

• Nothing to store, rotate, or leak. There is no secret at all — Azure proves the app's identity internally, and the credential behind it is managed and rotated by Azure, never visible to anyone.
• No IP allowlist to maintain. The identity itself is the gate, so infrastructure changes on your side don't break access.
• Revocation is instant and clean. WCM disables the identity registration and access stops — no key to chase down.

WCM allowlists your app's identity (its Object ID) and binds it to your client — see Setting it up. Runs show the MI Based badge with your app's name as the user, and files go to the mi archive folder — same auditing as every other channel.

Setting it up

Setup is a one-time exchange: you flip one switch in Azure and send WCM three pieces of information.

Step by step:

1. In the Azure portal, open your app → Identity → System assigned → On → Save. (CLI: az functionapp identity assign.)
2. Copy the Object (principal) ID that appears — a GUID identifying your app.
3. Send WCM the Object ID, a display name (use the app's name — it's what shows in the audit logs), and the client it should act for.
4. WCM registers and enables the identity. From then on your app's calls just work — no code changes when keys would otherwise rotate.

Calling the API from your app

Two lines of ceremony, then it's the exact same API as the API-key channel: request a token for Stargate's audience, send it as a Bearer header instead of X-Api-Key. Every command in the reference works identically.

Node.js (install @azure/identity):

PowerShell (inside the Azure app — uses the injected identity endpoint):

Any other language: use its Azure Identity SDK (ManagedIdentityCredential with the same api://…/.default scope), or call the raw identity endpoint as the PowerShell example does — it's plain HTTP.

The first-call test sequence:

1. Deploy and call /v1/me — expect { mode: "managed-identity", clientCode: "…" }.
2. If you get "This managed identity is not authorized" — token and network are fine; the registration just isn't done yet.
3. Then follow the same path as any API caller: /v1/connections → stage → transfer → history.

Setup guide to download (.md)

Hand the whole setup to your developers — or their AI assistant: download this Markdown guide and pass it along. It contains everything needed to configure an Azure Function App (or any Azure-hosted app) to connect to Stargate with its Managed Identity, end to end.

How to use it:

1. Click ⬇ Download — a plain-text Markdown file, readable in any editor.
2. Give it to whoever builds the integration: a developer can follow it top to bottom, or an AI assistant (Claude, etc.) can be told "read stargate-mi-setup.md and configure our Function App to connect to Stargate".
3. They enable the identity, send WCM the Object ID (per the guide), and verify with the built-in test sequence.

What's inside — the guide's sections and what each covers:

A connection is missing

The most common "problem" isn't a fault at all: every connection is enabled per channel, and a channel it isn't enabled for simply never sees it:

What this looks like in practice:

• The connection shows in this portal but your script's API call can't use its connId — or the other way around.
• Your AI assistant lists two connections when the portal shows three.
• A brand-new connection doesn't appear anywhere yet — its channels simply haven't been ticked.

The fix is always the same: ask your WCM administrator to check the connection's channel settings and tick the channel you need. It takes effect within about a minute.

A send looks failed / unconfirmed

Large transfers can outlive the request that started them: the browser (or API call) gives up waiting while the engine carries on — often finishing successfully. That's what Unconfirmed means: unknown, not failed.

The right sequence — verify before re-sending:

1. Open History and find the run (↻ Refresh — it may have finished since you last looked); open its Log.
2. If it shows delivered — done, don't re-send.
3. If it's still Running / Queued — wait; watch Job Status.
4. Only re-send once the run is conclusively Failed.

Sign-in refused or locked

Two different messages can appear after Microsoft accepts your credentials — they look similar but mean different things:

What each means and what to do:

Removing files from a connection

The Manage Items tab lists the files sitting in one connection's own folder and lets you permanently remove them — it exists to withdraw something sent by accident, before the other side picks it up.

1. Pick the connection — the listing shows that connection's folder and nothing else. The scope is enforced server-side: nothing outside this connection can be touched from here.
2. Tick the files to remove (optionally narrow with the subfolder box first).
3. Remove selected 🗑 — a confirmation box appears and you must type the word Delete before anything happens. One confirmation covers every file you ticked; a wrong or empty word cancels safely.

Removing an archived file

You'll notice the Archive tab has Re-Send and Encrypt/Decrypt — but no delete button. That's by design, not an omission:

Why: the archive is the proof of what was delivered, when, and in exactly what form. It's what makes Re-Send trustworthy and History verifiable — for you as much as for WCM. A quietly deletable archive would be worth much less the day you need it in a dispute.

When something genuinely must go (sent in error, contains data it shouldn't):

1. Contact WCM with the file name and the folder it's in (User / API / Managed Identity).
2. Say why — removal is handled administratively so the audit trail stays intact even when the file itself goes.

Contacting support

Contact your WCM representative — and include three things from History, which turn "something's wrong" into a case WCM can act on immediately:

Where to find each item:

1. Run name + start time — the first columns on History. Quote the time with its zone abbreviation from the header (see Time zones).
2. Status — the colored word on the run's row (what each means).
3. Log screenshot — click Log on the run and capture the timeline (how to read it). The ✖ step's verbatim error message is usually the whole diagnosis.