Connections
A connection is a team-to-team link between two different organizations. It is the prerequisite for everything cross-org in DICE: sharing a thread or folder with a partner team and sending them shipments both require an active connection whose direction allows the data to flow.
Connections live on the Connections page: “Pair your teams with external organizations using invite codes.”
How connections work
Section titled “How connections work”Connections are established with a secure, invite-code-based handshake — “A secure handshake between two organizations — no emails sent by DICE.” The Connections page summarizes it in four steps:
-
“You create the invite” — “DICE generates a link and QR code. It does not send an email.”
-
“You share the link yourself” — “Send the link over email, Slack, or any channel you trust.”
-
“Recipient accepts” — “A partner admin opens the link and accepts on behalf of their team.”
-
“You confirm to finalize” — “Come back here to confirm — the connection goes live on both sides.”
Because both an explicit accept and a confirm are required, neither side can be connected unilaterally.
Create an invite
Section titled “Create an invite”-
On the Connections page, click Create Invite.
-
Optionally set “Restrict to email” (marked Recommended): “If set, only the user signed into DICE with this exact email will be able to accept the invite.” Even if someone else gets the link, they can’t accept it. Without a restriction, “Any DICE admin who receives this link can accept it on behalf of their team.”
-
Choose the “Data flow direction” — see Direction below.
-
Click Generate Invite Link. DICE shows the invite link and a QR code. As the dialog notes: “DICE won’t email the invite for you” — “it’s up to you to send it to the recipient over whatever channel you trust — email, Slack, a phone call, etc.”
-
Copy the link and send it to the partner admin yourself.
Accept an invite (partner side)
Section titled “Accept an invite (partner side)”The recipient opens the link while signed into DICE and sees the Connection Request:
- Only a team admin can accept: “Accepting it joins your team to another organization’s team, so only an admin of the receiving team is allowed to do it.”
- The invite can’t be accepted from the same organization that sent it — invites only connect two separate organizations.
- The recipient picks which of their admin teams should receive the connection, then chooses Accept, Reject, or Decide Later.
Accepting is not the end: “Accepting won’t activate the connection yet — the requester still has to confirm on their end before data flows.”
Confirm the connection (requester side)
Section titled “Confirm the connection (requester side)”Back in your Connections table, the invite’s status flips to Accepted. Click Confirm to finalize — the connection becomes Connected and is active for both parties.
Statuses
Section titled “Statuses”| Status | Meaning |
|---|---|
| Pending | Invite created; waiting for the recipient to accept. |
| Accepted | The partner accepted; waiting for you to Confirm. |
| Connected | Active — sharing and shipments can flow (subject to direction). |
| Paused | Temporarily suspended by one side; shares and in-flight shipments are frozen. |
| Rejected | The recipient declined the invite. |
| Canceled | The invite was withdrawn before acceptance. |
Direction
Section titled “Direction”Every connection has a data-flow direction, set when the invite is created: “Control which direction thread data flows between the two teams.” From the creating team’s perspective the options are:
- Send — “Send thread data to the connected team.”
- Receive — “Receive thread data from the connected team.”
- Send & Receive — “Send and receive thread data with the connected team.”
Each side sees the direction from its own point of view (“Send to them” / “Receive from them” / “Send & Receive”). Direction gates both sharing and shipments: if the connection doesn’t allow your team to send to the partner, you can’t share items with them or pick them as a shipment recipient, and existing shares to them are suspended (see Sharing and access).
Change the direction
Section titled “Change the direction”Direction changes use the same double-confirmation as the original handshake. From the connection’s row, choose Change connection direction: “Propose a new data-flow direction. The other team must accept and you must confirm before it takes effect — the current direction stays in force until then.”
-
You pick the “New direction” and click Propose change. The row shows “Change pending →” with the proposed direction.
-
The other team accepts the change (“Direction change accepted — awaiting their confirmation”).
-
You confirm (“Direction change confirmed”) — only then does the new direction take effect.
Either side can cancel a pending change before it’s confirmed. If the new direction disallows existing shares, those shares are suspended until the direction allows them again.
Pause and resume
Section titled “Pause and resume”Pausing is a reversible freeze. The confirmation dialog (“Pause this connection?”) spells out the consequences: the shared items between your team and the partner “will be suspended — the other team loses access until you resume, and resuming restores everything automatically”, any in-flight shipments are frozen, and “Nothing is deleted.”
Resuming (Resume connection) restores everything: “Connection resumed — suspended shares restored.”
Delete
Section titled “Delete”Deleting a connection is permanent. The confirmation dialog (“Delete this connection?”) warns: “This permanently revokes all share grants between your team and the partner. … Reconnecting later starts sharing from zero. This cannot be undone.” In-flight shipments are canceled — but “Threads either team received through completed shipments are theirs and are not affected.”
Pending invites can be canceled or deleted from the same table without any of these consequences.
