Use Alfred in Slack

Alfred provides one guided entry point for starting and finding workflows. You do not need to remember workflow syntax.

Open the workflow launcher

1. Run /alfred in the channel where you are working.
2. Use the private launcher card to choose Onboard domain, Add subdomains, Update Lambda version, or Find execution.
3. Complete the focused modal.

The launcher is ephemeral, so only you can see it. Text after /alfred does not select an action or start a workflow; Alfred opens the same launcher.

You can open Alfred from any public channel. In a private channel, invite Alfred before running /alfred.

Review and confirm a workflow

Onboard domain accepts one primary domain per workflow. Enter a single domain such as example.com; comma-separated domains are rejected. Start a separate onboarding workflow for each additional primary domain.

The same normalized domain is used for registration and initial certificate setup. Alfred shows it on queued, running, failed, recovery, and completed cards.

Alfred validates the form and then shows a review screen. Check the target environment, requester, normalized domain, and certificate options before continuing.

Choose Back to edit the form or Confirm to start the workflow. Alfred does not create an execution, Slack binding, or tracking thread until you confirm. At confirmation, Alfred rechecks your permissions and protects the submission against duplicate Slack deliveries.

Add subdomains

Add subdomains accepts one root domain and between 1 and 10 relative labels. Separate labels with commas or new lines. For example, root domain example.com and labels blog, offers.eu create the hostnames blog.example.com and offers.eu.example.com. Do not enter complete hostnames in the label field.

The review screen shows every complete hostname before submission. This workflow changes Route53 only: Alfred mirrors the root domain's apex A-alias; it does not create certificates or change CDN, Helm, nginx, or other platform routing.

Alfred creates missing aliases and leaves matching aliases unchanged. If a label already has a CNAME or different A record, the workflow waits for approval before any mutation. Choose Review DNS replacements on the public root card, compare every current record with the proposed apex alias, and select Approve replacements. Alfred rechecks the plan immediately before the single Route53 transaction. If DNS changed during review, the approval is rejected and the refreshed plan must be reviewed separately.

Update a Lambda@Edge version

Choose Update Lambda version, then select Headout, MicroBrands, or MicroBrands Booking Flow. Headout and MicroBrands let you choose Test or Production. MicroBrands Booking Flow is Production-only. Choose Continue, then select one of the published numbered versions Alfred loads from Lambda. Aliases and $LATEST are never offered.

Choose Prepare review before confirming. Alfred resolves the exact uuid-assigner or uuid-assigner-test version and shows the immutable review:

• target and environment;
• resolved function and numbered ARN;
• distribution and association counts;
• current version groups;
• environment mismatches that will be repaired;
• protected behaviors that will remain unchanged; and
• already-current distributions.

Production confirmation uses an explicit production warning. Confirm update or Confirm production starts exactly the reviewed fleet. If the review expires or discovery, aliases, behaviors, or association membership change, Alfred does not expand the change. Choose Refresh review, inspect the replacement plan, and confirm again.

Alfred reads the CloudFront fleet with bounded concurrency while preparing the review. If Slack says CloudFront is busy, no workflow was started and no CloudFront or Lambda change was submitted. Wait a moment, reopen /alfred, and prepare the review again.

Alfred changes only the version on existing eligible Lambda@Edge associations. It never attaches or detaches an association. Headout behaviors containing api, assets, or _next stay unchanged; MicroBrands ordered behaviors stay unchanged; and kirby.headout.com is never updated.

Follow workflow progress

After confirmation, Alfred:

1. Privately acknowledges the request in the source channel.
2. Creates the canonical workflow thread in the configured operations channel.
3. Posts a public receipt in the source channel that links to the workflow thread.
4. Tracks durable progress on the canonical root card and in its thread.

The canonical root card is the live status surface. Alfred edits the root card in place as durable checkpoints arrive, including aggregate Lambda-version counts such as submitted, deployed, still deploying, failed, and unfinished distributions.

Thread replies record stage transitions rather than every batch checkpoint or provider poll. They retain the durable start, wait, completion, failure, and terminal-summary history without repeating unchanged progress. When Alfred reports a failure or exception for an individual CloudFront distribution, the message includes that distribution ID.

The acknowledgement after confirmation is ephemeral, so only the requester can see it. The canonical root card and durable milestone replies in its thread are normal channel messages. Everyone who can view the configured operations channel can follow the workflow updates there. Control responses and errors may be ephemeral, so only the person using the control sees them.

The canonical root card includes a Slack task plan for every workflow exposed by the launcher. Tasks follow the workflow's durable stage order and update from persisted stage records: active tasks are in progress, successful tasks are complete, failed tasks show an error, and waiting or unreached tasks remain pending. Recovery retries replace an earlier attempt with the latest persisted attempt for that stage. Compensation and newly introduced persisted stages are appended to the plan without exposing provider response bodies, credentials, or stack traces.

Milestone replies remain in the thread as an immutable event history; the task plan is the current summary. If Slack rejects native task-plan blocks with an unsupported-block validation error, Alfred records the delivery error and retries the same root as the legacy status card. Other Slack errors still fail normally. Native task plans do not require additional OAuth scopes or event subscriptions.

The public source receipt lets people in the source channel find the canonical thread. The root card identifies the immutable requester and links back to that receipt as View original request when Slack returns a valid permalink. If Slack does not return a permalink, Alfred shows the requester mention without a broken source link.

Duplicate and queued requests

If the same domain already has an active or recoverable onboarding execution, Alfred does not create another execution. The private response links the existing canonical workflow thread. If Slack has no thread permalink, the response provides View status instead. When the existing execution is failed or canceled and its persisted state supports recovery, the same duplicate response also provides Retry workflow. The action uses the existing reviewed inputs and permission checks; it does not create a second onboarding execution. A rolled-back execution is not recoverable. Start a new Onboard domain request; Alfred creates a new execution linked to the rolled-back audit record.

Different domains may wait for Alfred's shared infrastructure lane. The public workflow card names and links the blocking execution when possible. If that execution needs recovery, the waiting card says so explicitly. You can cancel your queued execution from its card.

Failure details

Failed cards replace the last successful progress message with the failed check, a bounded safe reason, and the recommended next step. Provider response bodies, credentials, and stack traces are never shown in Slack. Use Open dashboard for deeper technical inspection.

Follow domain onboarding phases

One Onboard domain request creates one execution, Workflow SDK run, dashboard run, and canonical Slack thread. Alfred reports these phases in order:

1. Register the primary domain, or confirm that it is already registered.
2. Plan the certificate topology.
3. Create or adopt the certificate.
4. Configure the Kirby and nginx CloudFront distributions.
5. Link the certificate to the required load balancers.
6. Update Helm platform routing, wait for ArgoCD convergence, and ensure the legacy nginx booking whitelist is present.
7. Finalize DNS and old-certificate cleanup.
8. Add the root and wildcard browser referrers to the Kirby and Zapdos Google Maps API keys.
9. Complete Zendesk and the onboarding execution.

Registration must succeed before certificate or infrastructure mutations begin.

If the highest-ranked reusable certificate spans multiple CloudFront distributions, Alfred checks the remaining eligible certificates in order. It uses the first candidate with unified alias ownership, or explains that it is using an isolated certificate group when none qualify. Existing aliases and distributions are left unchanged.

The root status card always provides a refresh control. While an execution is active, it also provides Cancel execution. The cancel action disappears after the execution succeeds, fails, is canceled, or is rolled back. Cancellation opens another confirmation dialog, and Alfred rechecks the requesting user's permission before changing the execution.

For add-subdomain, cancellation is available while planning or awaiting replacement approval. It disappears after Route53 accepts the change because the provider mutation can no longer be safely canceled.

When ALFRED_WORKFLOW_DASHBOARD_URL is configured, the root card also links to the corresponding Workflow SDK run. The link does not contain Alfred API credentials. The dashboard or its access proxy authenticates and authorizes viewers independently from Slack.

When onboarding reaches a terminal state, the root card shows a compact Outcome with the primary domain, certificate ID, Kirby and nginx distribution IDs, cleanup state, Google Maps state, and whether assistance is required. Alfred also posts one Execution summary reply for each terminal Workflow SDK run. The reply contains full copyable artifact identifiers, Zendesk state, cleanup details, and explicit labels for artifacts that were not created or not reached.

Normal terminal summaries do not mention people. Alfred mentions @platform-oncall and Dhruv only when persisted structured infrastructure state explicitly requires manual Platform action. A generic failure, a retryable provider error, or a missing optional artifact does not trigger those mentions.

If booking whitelist entries are missing, Alfred validates and atomically commits the Calipso and next-deimos changes to the configured nginx base branch after Helm routing has converged. The execution summary mentions @platform-oncall and Dhruv because production nginx deployment remains manual; review and merge are not required. If the required entries already exist on the base branch, no commit or manual-assistance mention is created.

When a persisted Zendesk completion or correction fails, Alfred instead mentions only the immutable Slack requester. The summary includes the ticket ID and intended manual action. Platform and Zendesk assistance appear in separate sections when both are required. Summaries are deduplicated per Workflow SDK run, and unchanged assistance is not mentioned again after tracking restarts or recovery.

If Google Maps referrers cannot be reconciled, domain infrastructure remains successful and the Zendesk ticket stays open with an internal pending comment. Alfred mentions only the immutable requester. After capacity, credentials, or the provider error is resolved, choose Retry Maps whitelist. This retries only Google Maps and completion; it does not rerun infrastructure stages.

Recover a workflow

Retry workflow appears on both the canonical root card and private status cards whenever the execution is eligible. Other recovery controls also appear only when the current execution state supports them:

All workflows exposed by the launcher run through Workflow SDK and support retry from an eligible failed or canceled execution. Lambda version retry reuses the reviewed plan and completed work and submits only failed or untouched distributions. Retry is unavailable after restoration begins.

A rolled-back execution is permanently terminal. Alfred hides its retry controls and rejects stale retry actions. To run the workflow again, open /alfred and submit a fresh request. Alfred creates a new execution linked to the rolled-back one; it does not alter or restart the original audit record.

For an active Lambda version update, cancellation stops future CloudFront submissions but does not interrupt a write CloudFront has already accepted. Alfred observes those accepted distributions before reporting the canceled result. For a terminal update with receipts, Restore previous versions opens a confirmation dialog and restores the exact prior ARN for each recorded association. Alfred refuses to overwrite association drift.

Choose a retry action to open a focused confirmation dialog. It shows the workflow, execution ID, current status, selected action, and persisted workflow inputs. The inputs are read-only: Alfred always retries the reviewed, persisted request instead of accepting changes during recovery. Choose Confirm retry to continue or Keep current state to close the dialog without changing the execution.

Alfred rechecks the execution's workflows:<name> permission, status, and recovery eligibility when the dialog is submitted. If another action changed the execution in the meantime, Alfred performs no recovery mutation and reports the current status privately. Refresh the root card before choosing another action.

An eligible onboarding finalization retry is a failed onboard-domain execution at stage-6-finalization with a source Workflow SDK run and successful persisted registration, certificate, distribution, load-balancer, and platform-routing outputs. Standalone add-certificate retains its existing finalization recovery contract. Retry finalization reuses the required outputs and queues only finalization. Retry workflow starts or continues the workflow from its persisted inputs, reusing completed durable work when safe.

After Alfred durably queues a recovery, it posts a public Retry requested by @requester milestone in the existing canonical workflow thread. The same root card, thread, and earlier milestone history remain visible; Alfred appends updates from the recovered Workflow SDK run there. While the recovery is waiting for its new run, Alfred does not stream the previous terminal run. Finalization recovery preserves the execution's original source-run lineage; Alfred follows the recovery command's run separately and uses it to update the root card, post one recovery-specific terminal summary, and complete the Slack binding. A recovery that finishes before the tracker polls still refreshes the root card to its terminal execution status.

Find an execution

Choose Find execution from the private launcher, enter the execution ID, and submit the modal. If you are authorized, Alfred returns a private status card in the source channel.

Configure the Slack app

1. Create or update the app from apps/api/slack-app-manifest.yaml.

2. Install the app to the workspace. Reinstall it whenever the manifest gains a new OAuth scope. Live user-group authorization requires the usergroups:read bot scope. Task plans use the existing message permissions and do not require reinstalling the app.

3. Add Alfred to the operations channel and to every private channel where people need to use it.

4. Configure SLACK_BOT_TOKEN, SLACK_SIGNING_SECRET, and ALFRED_SLACK_WORKFLOW_CHANNEL_ID on the API service.

5. Configure ALFRED_SLACK_OPERATOR_USERGROUP_IDS with comma-separated, immutable Slack group IDs. Headout grants workflow-operator access to @engg-acquisition and @engg-platform:

   SS803F5B5,S04AM72SB4Y

   Store immutable IDs beginning with S, not editable handles or display names. ALFRED_SLACK_OPERATOR_USERGROUP_ID remains supported for one legacy group. If both variables are present, Alfred deduplicates and checks their union.

6. Optionally configure ALFRED_WORKFLOW_DASHBOARD_URL with a credential-free HTTPS URL for the Workflow SDK dashboard. It may have no query string or exactly one non-empty environment parameter. Do not include other query parameters, a URL fragment, or embedded username and password credentials.

7. Configure ALFRED_SLACK_PLATFORM_ONCALL_USERGROUP_ID with the immutable Slack user-group ID for @platform-oncall and ALFRED_SLACK_DHRUV_USER_ID with Dhruv's immutable Slack user ID. The values must begin with S and U, respectively. Alfred disables malformed Platform mentions without disabling workflows, normal summaries, or requester-only Zendesk assistance.

8. Grant any additional Alfred roles to principals shaped as slack:<workspace-id>:<user-id>.

Each Slack action needs the single permission for its workflow. For example, onboarding uses workflows:onboard-domain, and submission, plan review, approval, cancellation, and retry for add-subdomain all use workflows:add-subdomain. Add-subdomain does not expose rollback.

Workflow-operator access

Alfred checks live membership of every configured Slack user group. Membership in either configured Headout group grants every supported workflow permission. Alfred caches each workspace and group's membership snapshot independently for 60 seconds, so membership changes can take up to one minute to affect authorization.

Verified members receive the five workflow permissions in Slack:

• workflows:onboard-domain
• workflows:add-certificate
• workflows:add-domain
• workflows:add-subdomain
• workflows:update-lambda-version

Group membership does not grant wildcard access, security administration, audit access, or principal, subscription, and API-key management. This supplement applies to Slack interactions only and does not change bearer API permissions.

If one group lookup fails, a membership verified through another group still grants workflow access. If no group verifies membership and any group lookup is unavailable, Alfred fails closed for group-derived access and asks the requester to try again. Permissions from roles assigned directly to the requester's slack:<workspace-id>:<user-id> principal remain available during that failure.

The app uses direct Slack request signing. Socket Mode and a forwarding service are not required.