Requested, connected, sent, delivered: read integration status correctly

Separate four levels of evidence

Treat integration status as an evidence ladder rather than a single on/off switch. First, someone may request an integration that is not operationally available. Second, authorization can establish access to an account. Third, a provider can accept an individual operation. Fourth, you can inspect the intended destination and confirm the expected result. Each observation answers a different question.

The phrase delivered is particularly easy to overread. A message appearing in a Slack channel is not proof that the responsible person saw it, understood it, or acted. Likewise, a calendar event existing is not proof that every attendee accepted it. If the workflow requires acknowledgement, make that acknowledgement an explicit human step rather than inferring it from a technical status.

Record the strongest evidence you actually have. A precise note such as Provider accepted test at 14:10; visible in intended channel at 14:11 is more useful than Integration works. It narrows future diagnosis and avoids a false promise about every subsequent delivery.

Read the connection detail, not just the card

In Critical Path, open Settings → Connections and inspect the relevant provider. Check the authorized account or managed destination, connection owner, permission receipt, and recent activity. A workspace-level connection may be managed by an owner or administrator rather than by every member independently.

For calendars, identify the connection selected for workspace writes. An authorized account that is not selected is not necessarily the one receiving the blocks you are inspecting. For Slack, identify the channel or destination label and whether routing is active, unverified, temporarily degraded, or paused pending action. These distinctions are intentionally separate from the fact that authorization once succeeded.

A Request control records demand for a connection; it does not install a working integration. If the screen offers a request instead of authorization, do not configure a task's communication expectations as if the provider were already available. Use an operational channel while the request remains unresolved, and tell collaborators where they should actually expect follow-up.

Verify Slack with one deliberate visible message

Slack incoming webhooks are associated with a destination selected during authorization. Their URLs are secrets, not harmless diagnostic links. Slack documents successful responses and several rejection cases, including archived channels and invalid or disabled destinations. Do not paste a webhook URL into a support ticket, screenshot, public article, or chat transcript.

Critical Path exposes Send test to eligible workspace owners and administrators when a routable Slack destination exists. The interface states that it posts one visible test message and changes no action items. Its success response means Slack accepted that message. The app records destination-specific verification health; replacing a destination should not inherit proof about an old one.

Before sending, confirm that a visible test is appropriate for the chosen channel. Afterward, open that exact Slack workspace and destination and look for the test. If the provider accepted it but you cannot find it, first check the workspace, channel, access, and timestamp. Do not repeatedly send tests to a busy team channel simply because the first one was not immediately visible to you.

1. Check destination and connection ownership in Settings → Connections.
2. Ensure you are authorized to post a visible verification message there.
3. Choose Send test once and record the result and time.
4. Open the intended Slack destination and confirm the message is visible.
5. If it is absent or rejected, record the safe error text and investigate the destination or authorization before retrying.

Sources: Slack: incoming webhook destinations, secrets, and responses

Trace a calendar block from task to provider

Calendar verification needs a different final observation. Choose one existing task and record its allocation and scheduled start and end. Open the connected calendar and identify the corresponding event. Compare the interval, relevant timezone, and calendar account. Then inspect neighboring events to see whether the spacing policy is respected.

The current Critical Path policy attempts reconciliation every five minutes and uses 15-minute action-item separation. Those are application policies, not universal Google Calendar features. A disconnected account, incomplete availability read, failed write, or unconfirmed result can prevent the intended state from being reached. Read the connection activity and task block state before assuming that another invitation will solve the problem.

Color is a visual preference, not proof of identity, availability, or synchronization. Google explains that an event color set in your calendar is not generally the color other people see. Critical Path can synchronize its configured color through the authorized account, but an email sender alone does not force every recipient's Google Calendar display. Diagnose missing events and stale times independently from color mismatches.

Sources: Google Calendar: event colors and visibility to other people

Worked example: authorization passes but follow-up is missing

A fictional operations team expects a reminder in its delivery channel. The Slack card says authorization is active, but the destination label refers to an old review channel. The team sends one approved test; Slack accepts it and the message appears in that old channel. This is not a transport failure. It is a destination mismatch between the configured route and the team's expectation.

The owner corrects the connection destination through the supported authorization or managed configuration path, then performs a new approved verification. Only after the new destination is observed should the team rely on it. Existing reminder configuration must still include an appropriate channel and future schedule. A successful test does not manufacture a reminder event for a task that has none.

Escalate with a small, private evidence packet

For a transient failure, allow the application's retry behavior to operate and avoid creating duplicate manual messages. For an action-required state, resolve the destination or authorization issue rather than waiting indefinitely. Critical Path differentiates these cases: a temporary Slack failure can leave routing active, while a rejected destination can pause it until corrected.

The downloadable verification log asks for observed status, approximate time with timezone, intended destination label, result, and the next owner. It deliberately does not request access tokens, webhook URLs, invitation tokens, private calendar feed links, or full task exports. Keep any task identifiers or screenshots in the approved private support channel and remove unrelated content.

Finish diagnosis by confirming the original use case, not only the test control. A harmless test proves one path at one moment. The real requirement may also depend on reminder timing, a task's current status, quiet hours, or a person acknowledging a handoff. Separate those checks and report what remains unverified. Reliability improves when uncertainty is named precisely enough to act on it.

Common questions