The case shows what is expected, who needs to act and where the information came from.

His email arrives in your organisation’s mailbox. The sender, reference and source message stay available so you can check what was actually requested.

Case C-024 brings the request and checklist together. Identify the invoice, reply to John and track receipt of the requested document.

The next action is to prepare a message. Creating a case does not reply to the requester or prove receipt of the invoice or payment.

An uncertain association needs review; a draft is not evidence that an email was sent.

Use the demo button to read the draft. Sending is simulated here; in the product, you send the reviewed message from Gmail or Outlook.

Detecting the sent email provides evidence of sending. The case can then wait for an external reply; a draft alone does not justify that change.

John’s request and reference INV-204 remain available beside the prepared text. Keep the conversation’s context at hand when reviewing your response.

The three-day reminder prompts a follow-up draft, without automatically sending a message.

The timeline keeps the case creation and sent reply. The checklist separates completed actions from the document that is still missing.

Advance the fictional dates to reach the reminder. It prompts a check within Tamdot, not a new email automatically sent to the contact.

The detected reply explains the external wait. The case stays open until the requested document is received and the result is checked.

The received invoice and closure note remain available; receiving an invoice does not prove it was paid.

Her email includes INV-204.pdf. The common reference connects her reply to the original request without creating a second case for the same invoice.

The timeline adds receipt of the invoice. The actions for this document request are complete, so the case moves to Completed.

Open the demo result to see the document and closure note. Receiving an invoice is not evidence that the invoice has been paid.

The contact, duration and preferred day guide the search, without booking or confirming a slot.

His email asks for a 30-minute consultation. The request is linked to case A-018 and Jonas Weber; no appointment has been booked yet.

The requested day, duration and contact come from this conversation. They inform the search for a suitable slot without inventing a confirmation.

The next chapter shows working hours, reviewed leave and the required room. Receiving a request does not mean a person or resource is free.

Booked slots stay visible; the check uses Tamdot’s records, without synchronizing external calendars.

Return to the original email: a 30-minute consultation. The request stays linked to case A-018 while availability is checked.

Working hours, reviewed leave and resources are considered. The example also shows a July leave declaration reviewed by the team.

Already booked slots are not shown as free. Other slots remain possibilities: an available time is not yet a confirmed appointment.

Review the draft and send it from your mail client; the proposal does not confirm the appointment.

The contact, requested Tuesday and 30-minute duration stay visible. Compare the proposed slot with the email that initiated the request.

Jonas Weber and Room 1 are part of the check. The booked slot stays visible so you can understand why another time is proposed.

The slot shows the person, room and duration. Review the text before sending it in your mail app; the appointment is not yet confirmed.

Confirmation is recorded in Tamdot; no external calendar is modified.

In this example, the team explicitly confirmed the appointment. Its status does not change merely because a draft or proposal was prepared.

The confirmation brings together the contact, owner, resource and case A-018. The context of the agreed appointment stays immediately available.

Your team keeps the decision and can record the outcome. This does not mean an external calendar was changed: external calendars are not synchronized.

The ticket tracks a support need, separately from an appointment request or a document case.

The request arrives in the Outlook support mailbox. The email says the reset link has expired, keeping the problem readable in its source.

This email belongs to the Tickets workflow, not appointment planning. The selected mailbox and nature of the request guide the work to be done.

The problem still needs assessment, a priority and an owner. Receipt of the message does not establish that access has been restored.

Priority and targets depend on your rules; they are not evidence that the problem is resolved.

The expired link explains the ticket. Keep the source available to check the symptom and prepare a response that matches the reported issue.

The ticket retains the contact and login problem. Its status describes progress separately from urgency or the requested deadline.

The four-hour deadline illustrates an SLA rule. It tells the team when to act; it is neither a guarantee nor evidence of resolution.

Article K-008 provides a starting point, not an automatically approved or sent response.

The owner appears beside status and priority. Your team knows who must act without searching every message for that information.

Article K-008 suggests requesting a fresh reset link. It is shown with the ticket context so you can check its relevance before using it.

Adapt the text, check the assignee’s availability and send from your mail app. A suggestion does not prove the customer can log in again.

Preparing or sending a reply does not prove that access has been restored.

The ticket keeps its identity and Alex’s contact details. The status change follows a checked outcome, not simply preparation of a reply.

The example records restored access and Léa’s validation. Resolution rests on that confirmation rather than an assumption.

Article K-008 remains linked to its source ticket. It explains using the latest link and checking access to help with a future similar request.

Tamdot never sends, moves or modifies messages; connection credentials are encrypted.

Gmail and Outlook are shown with read access. See which connections supply the messages used in cases, appointments and tickets.

The shown access grants no sending, editing or deletion of emails. Prepared replies are reviewed and sent from your own mail client.

The panel describes AES-256-GCM encryption of connection tokens, not encryption of email content.

Disconnecting a mailbox ends its access; it is not a deletion request for information already retained.

Disconnect and reconnect the fictional mailbox to see its state change. This demo touches no real account and changes no provider messages.

The switch affects only the displayed example. It illustrates the difference between connection state and receiving notifications.

The analysis period and events stay visible. Disconnection, reconnection and notification changes are recorded in this demo’s local activity log.

Sharing respects roles and source permissions; it does not open every mailbox to every member.

John’s request and Jane’s invoice stay linked to INV-204. Teammates do not have to reconstruct the request’s history separately.

John Smith and Jonas Weber illustrate workspace roles. Sharing remains subject to member access and organisational boundaries.

Both team connections appear in the shared case. That does not automatically grant access to every mailbox or message.

Fictional example: an English email feeds a French-language case. Changing the interface does not rewrite its history.

This example uses a French workspace, so the C-024 summary is in French even though the received message is English. The workspace setting applies to new content without rewriting history.

The interface supports French, English and German. Your personal preference can differ from the workspace language: it changes labels, not the case. This showcase illustrates that preference in the language of this page.

The same fictional email and INV-204 reference remain visible. The summary is separate content, not a translation of the message: interface language replaces neither the source nor the facts of the case.

You stay in control of replies and confirmations; available applications depend on your plan and permissions.

The INV-204 request is complete because the requested document was received. Its result stays linked to the source, with no payment validation presumed.

Tuesday at 14:30 answers Sam’s request. Availability, ownership and confirmation have remained distinct throughout the workflow.

Alex’s access is restored after verification. Each workflow keeps its own context and a clear next step without confusing a draft with an outcome.