Two engineers agree in a direct message that Billing will publish an event instead of calling Notifications directly. The choice may be sound, and the private conversation may contain details that should stay private. The risk appears later: a new engineer sees an unexplained event boundary but cannot find the rationale, affected owners, or current status.
Direct answer: Keep the private conversation private, but put any decision that constrains shared architecture in a durable record that the people who need to act on it can access. Share a sanitized summary only with an audience allowed to see it. Record the decision’s status, owner, reason, consequences, implementation task, and relevant diagram version. A channel post can route reviewers to that record; it does not have to reproduce the DM or serve as the canonical record.
The issue is not that Slack DMs are inherently unsafe or temporary. The issue is that their audience is limited to participants, while a shared design may affect people who were not in the conversation. Choose a record and audience that preserve both confidentiality and the technical context future maintainers need.
A DM is private, but not automatically temporary
In Slack, a message in a channel is visible to people who can access that channel; a private-channel message is limited to invited members, and a DM is sent to its named recipient or group. A copied link does not grant access to the full private conversation, but Slack offers a Show message option that shares the linked message in the destination; Only show link shares only the link. Check the message content and destination audience before forwarding it or choosing Show message. Slack’s guide to message visibility explains these audience boundaries; its forwarding instructions explain the message and link options.
DM retention also depends on workspace settings. Slack lets administrators configure retention for DMs as well as channels. On paid plans, members may be allowed to set retention for their own DMs and private channels. Pinned or saved messages still follow retention settings. So a DM may remain available for a long time, or it may be removed sooner under the applicable policy; check the workspace’s actual settings before treating it as the only record. Slack documents message-retention options and member overrides.
Slack distinguishes a message sent to an app in its own DM from a person-to-person DM. An app configured to receive messages in its own DM must subscribe to the message.im event and request the im:history scope; that is separate from searching a person’s other DM conversations. For Arialine, the current privacy policy describes historical search and states that private-channel and DM history are not supported as search sources. Check an app’s documented scopes and data policy before sending it sensitive information. Slack documents the message.im event and required scope; Arialine’s privacy policy describes its historical-search boundary.
Decide what needs to leave the DM
Promote a decision when it changes a contract or system behavior that other people will build, operate, review, or support. Examples include a service boundary, an event schema, a security control, an availability requirement, or a dependency other teams must maintain. AWS’s ADR guidance lists architecture structure, quality requirements, dependencies, interfaces, and construction choices as decision categories.
Do not promote the transcript by default. A private exchange may contain customer identifiers, credentials, incident details, personnel information, speculation, or disagreement that the wider audience does not need. Preserve only the minimum technical consequence and rationale needed by each audience. Keep restricted evidence in its approved system and link to it only when the recipients are authorized to open it.
A short coordination question with no lasting effect may need no separate decision record. If the DM settles a shared architectural question, make the accepted outcome discoverable in the canonical record even when the original discussion remains restricted.
Choose a record with the right access
| Record | Use it for | Check before sharing |
|---|---|---|
| ADR or design record in the affected repository | Decision status, context, alternatives, rationale, consequences, and supersession | Repository visibility matches the decision’s sensitivity and affected teams |
| Restricted security, incident, or customer record | Sensitive evidence, payload details, or threat analysis | Access is limited to the approved people; do not expose the record’s existence if that is sensitive |
| Pull request, issue, or delivery task | Implementation owner, acceptance criteria, rollout, and verification | It links to the decision rather than asking implementers to reconstruct it from a DM |
| Slack channel post | A brief handoff, request for review, or pointer to the canonical record | The channel audience is allowed to see every detail in the post |
| Architecture diagram | Components, boundaries, and flows affected by the decision | It is labeled proposed, accepted target, or verified deployed state as appropriate |
An architecture decision record (ADR) is a useful format for decisions with lasting design consequences, but a team can use another governed record if it captures the same information. AWS recommends recording context, the decision, consequences, ownership, and review state; its process keeps a decision proposed until the responsible review accepts it. A Slack reaction or channel reply should not be described as formal approval unless that is the team’s defined approval process.
Promote the outcome in five steps
- Name the decision and state. Is it proposed, accepted, rejected, or superseded? Identify the person or process with authority to set that state.
- Classify the information. Identify the audience that needs to act. Remove secrets, customer details, and private context that audience is not allowed to see.
- Choose the canonical record. Put the decision where its owner will maintain it: usually an ADR or design record for architecture, a restricted record for sensitive evidence, and a separate issue or pull request for implementation.
- Write a scoped summary. State the technical change, the reason that can be shared, consequences, owners, open questions, and links the intended readers can access.
- Align the diagram and follow-up. Link the relevant diagram version and implementation task. Mark a diagram as deployed only after checking it against the environment and revision that actually shipped.
If a channel summary is safe and useful, post it in the channel where affected owners coordinate. If it would disclose protected information, do not post the details there. Update the access-controlled record and send only an approved pointer or generic handoff to the wider audience.
Copy this privacy-aware promotion template
Use only the fields that help this decision. Do not paste the DM transcript into the shared record.
Decision: <one sentence describing the technical consequence>
Status: Proposed | Accepted | Rejected | Superseded
Owner / acceptance process: <person or named process>
Affected systems and owners: <teams that need to review or act>
Shareable reason: <constraints and trade-offs safe for this audience>
Open risks or questions: <what remains unresolved>
Canonical decision record: <link this audience can open>
Implementation task: <owner, acceptance criteria, and rollout link>
Diagram: <source and version; label target or deployed state>
Restricted detail: <approved restricted record, only if its existence is safe to disclose>
If the decision is not accepted yet, say so. A summary must not convert “we could do this” into a team commitment. If the DM participants disagree about what was decided, leave the record proposed and ask the authorized decision owner to resolve the state.
Example: share the event boundary, restrict the payload details
For example, two engineers discuss a Billing-to-Notifications event in a DM. The payload includes sensitive customer data, so the complete schema belongs in a restricted design record.
A safe channel post for a team that may know the architecture could say: “Proposed: Notifications consumes invoice.sent; Billing emits it after the invoice record is durable. Billing and Notifications owners, please review retry behavior and duplicate delivery. The payload schema remains in the approved restricted record.” The post names the change and the review needed without copying sensitive fields or implying approval.
After the decision owner accepts the design, update the ADR and link the implementation task. Update the diagram to show the accepted target architecture. Once the change is deployed, verify the relevant environment and revision before labeling that diagram as deployed. The decision, code delivery, and diagram state answer different questions and should not be collapsed into one status.
Where Arialine fits
Arialine can help update a shared Mermaid diagram after someone explicitly requests a change in a channel where the app is invited. Use a sanitized promotion post as the source when the private DM itself should remain private. The board keeps diagram versions and source links to the Slack requests that informed them; it does not establish who had authority to decide, prove consensus, or verify deployed behavior. See the architecture review workflow when a shared diagram is part of the review, and the architecture decision capture guide for a fuller ADR template.
Do not send sensitive content to an AI-assisted workflow unless your organization permits that processing. Arialine’s privacy policy explains request context and model-provider processing. A direct message to the app is a separate explicit request, not authorization to search other people’s DMs.
Check that the record works for someone outside the DM
Ask a teammate who was not in the conversation and does not have access to the private thread to follow the record. Can they explain what was decided, who accepted it, which systems are affected, and what remains to be implemented? Can they open the cited record and identify whether the diagram shows a proposal, target design, or deployed state?
If they need the DM participants to interpret a vague summary, add the missing shareable rationale or owner. If a needed detail is restricted, give them an approved route to request access rather than copying it into a wider channel. If ownership or acceptance is unclear, preserve that uncertainty in the record instead of inventing consensus.
Next step: take one recent DM decision that affects another team, write the minimum safe summary, and place it in the canonical record with an owner and status. Ask an uninvolved teammate to verify that the record is useful and that its links respect the intended access boundary.
FAQ
Must a decision made in a DM be posted publicly?
No. A public channel is only appropriate if its readers are allowed to see the information. Use the smallest audience that still includes the decision owner and affected maintainers. The canonical record can be access-controlled.
Is linking to the DM enough?
Only for readers who are participants and permitted to use that conversation as the governed record. A link does not grant access to nonparticipants. Put a concise decision summary in a record those who must maintain the system can open.
Are Slack DMs automatically deleted sooner than channel messages?
Not necessarily. Workspace retention settings apply to DMs, and member-specific overrides may be enabled on paid plans. Check your workspace policy; a pinned or saved DM can still be subject to retention.
Can Arialine search a DM between two people?
No. Arialine’s historical search covers public channels, on a member’s request, and never reads private channels or human-to-human DMs. Slack’s message.im event for app-directed messages is a separate access path, not a search of a person’s other private conversations. See Arialine’s current privacy and context limits.
Update note
Updated September 29, 2026: clarified Slack DM visibility and retention, separated app-directed requests from historical DM search, and added an access-aware decision-promotion workflow.
Add to my Slack