# Resolving a case

Resolving a case writes an outcome, names who decided it and closes the record — and changes almost nothing else. The lifecycle stage stays where it was, open follow-ups stay open, conversations stay where they happened, and the case itself stays attached to the person for good. Closing is a statement about one issue, not a tidy-up of the relationship around it.

- **Status:** Available
- **Audience:** both
- **In the app:** #/relationships, #/data
- **Last verified:** 2026-09-10
- **Canonical:** https://connectbyjbrh.com/docs/support/resolving/

## What closing writes down

`resolve_case` takes an outcome and closes the record with it. The outcome is the part that earns its keep six months later, when somebody reads the person's history and needs to know not that a problem ended but how. A case closed with nothing but a status is a case that will be investigated again from scratch the next time it recurs.

**The outcome** — What was actually done or decided, in the workspace's words.
**Who closed it** — A person, or the Assistant acting on an instruction. Both are recorded; neither is anonymous.
**When** — The closing time, which is what makes 'open for eleven days' a fact rather than an impression.
**The work before it** — Everything recorded against the case while it was open stays readable after it closes.

## What it does not touch

| Thing | Why closing does not move it |
|---|---|
| The lifecycle stage | Stage is a fact about the relationship, moved by its own action. A resolved complaint does not promote or demote anybody |
| Open follow-ups | A commitment has its own reason and its own due time. Silently cancelling promises because an issue closed is how a business stops being trusted |
| Conversations and threads | They stay on their channels with their own state. A closed case does not close an email thread |
| The case itself | It remains attached to the person permanently, because the next problem is often best understood by reading the last one |

> **Careful** If closing a case should also stop a chase, cancel the follow-up explicitly and say why. Two separate records that both need a decision is more work than one that guesses — and considerably less damaging than a promise that vanished without anybody choosing to break it.

## Closing it from where you are

1. From the relationship record, close the case with an outcome that would answer a stranger's question about it.
   - Result: The person's history reads as a sequence of resolved things rather than a list of statuses.
2. Or tell the Assistant to resolve it. `resolve_case` is one of its product tools, so a case can be closed in the same conversation where you worked out that it should be.
   - Result: The closure is recorded against the instruction that caused it, and the Assistant's narrower rights still apply — nothing commercial moves because a case closed.
3. For a batch, work the `cases` sheet in the Data grid.
   - Result: Bulk work still goes through the service that owns the record, so the outcomes are written the same way as if you had opened each one.

## When the problem comes back

Connect's case vocabulary is three verbs — open, act on, resolve — and no separate reopening step is documented. In practice that is less restrictive than it sounds: a problem that returns is a new case, and the resolved one sits in the same person's history where it explains the new one at a glance. A recurring fault then reads as recurring, with dates, which is exactly the shape somebody needs to argue for a real fix.

The alternative — reopening the original — produces one record with two beginnings and no honest duration. Anyone measuring how long customers wait would be measuring a fiction.

## What resolution is worth later

- It is part of the context the next case is answered from, so the answer knows this has happened before.
- It is on the timeline in the order the customer experienced it, next to the calls and messages that surrounded it.
- It is in the `cases` sheet, so open-versus-resolved is a filter rather than a project.
- It is in the audit trail with the person who decided it, which is the question that gets asked when a decision is queried months later.

## Questions

### Does resolving a case cancel the follow-ups attached to it?

No. Each commitment keeps its own reason and due time, and cancelling one is a separate decision with its own record. If the chase is no longer wanted, cancel it and say why.

### Can the Assistant close a case?

Yes, `resolve_case` is one of its product tools. The closure names the instruction that caused it, and the Assistant's rights stay narrower than a person's — closing a case does not let it touch pricing or a do-not-contact entry.

### How do I handle a problem that comes back after closure?

Open a new case. No reopening step is documented, and a fresh record keeps the durations honest while the earlier resolved case stays on the person's history explaining the pattern.

## Related

- [Support cases](https://connectbyjbrh.com/docs/support/cases/)
- [What a case carries](https://connectbyjbrh.com/docs/support/case-context/)
- [Escalating a case](https://connectbyjbrh.com/docs/support/case-escalation/)
- [A support case, end to end](https://connectbyjbrh.com/docs/workflows/support-case/)
- [Lifecycle stages](https://connectbyjbrh.com/docs/relationships/lifecycle-stages/)
- [Files and data in Connect](https://connectbyjbrh.com/docs/files-data/)

## What this page is based on

- `docs-source/sources/CHANNELS.md` §5 — `resolve_case`, `act_on_case` and `journey.py`
- `docs-source/sources/GENERAL.md` §8 — the Assistant's `resolve_case` and its narrower rights
- `docs-source/sources/GENERAL.md` §9 — the `cases` sheet and edits going through the owning service
- Connect capability registry (docs-source/facts.py) — `support_cases`, `audit_trail`