Sharing a category means giving someone else access to that branch of your tree — the category, its subcategories, its entries and its annotations. The classic case is a couple who want to see household expenses together without merging everything else. You choose who, which category and how much access; and you can revoke it whenever you want.
Before you start
Sharing is the one feature that depends entirely on the server, so there are three conditions:
- Being signed in to an account.
- Having given the sync consent — the data needs to be allowed to travel.
- Having a valid usage authorization: an active subscription or a running trial period.
The screen tells you which of the three is missing, instead of simply not working.
The two access levels
| Level | The other person can | Cannot |
|---|---|---|
| Read only | See the category, the entries and the annotations; use them in searches and totals. | Edit or create anything inside it. |
| Read and content | Everything read-only allows, plus creating and editing entries and annotations inside the category. | Touch the structure: rename, move, delete the category or create subcategories. |
You can switch between the two levels later, without redoing the invitation. The structure inside the category always belongs to whoever shared it — at neither level does the guest rename it, create subcategories or touch the hierarchy within. Where it sits in each person's tree is another matter: see the next section.
Each person arranges their own tree
The shared category arrives on the guest's device as a root category, even when it is a subcategory of something else on the owner's device. But it does not have to stay there: each person decides where the shared category sits in their own tree, and in what order among its siblings.
- The guest can drag the received category into one of their own — "Shared household" landing inside "Home", say — and order it among the rest.
- The owner keeps it wherever it has always been. Neither choice affects the other, and every device of the same person picks up that person's arrangement on the next sync.
- It is a preference of yours, not a change to the category: whoever shared it never sees where you put it, and the app never sends that position as if it were a structure change.
What the app refuses, with a message saying why:
| Attempt | Why |
|---|---|
| Moving a subcategory that came with it | The structure inside belongs to the owner; only the shared category itself can be repositioned. |
| Putting the received category inside another shared category | Its content would look like part of a share it has nothing to do with. |
| Putting the received category inside a category you share with someone else | That third person would see a branch nobody ever gave them. |
| Putting a category of your own inside a shared one | It would be invisible to the owner and orphaned once the share ended. |
If you tucked a shared category inside one of your own, deleting that category of yours is blocked — the delete would take the owner's content down with it. Move the shared one elsewhere (or leave the share) and deleting works again.
When the share ends, that preference has nothing left to describe: the app finds it and erases it, on the device and on the server, leaving nothing behind.
Three ways to point at the person
A share always ends up tied to a PaNotas account. What changes is what you need to know to get there.
| Way | When to use it | What you need to know |
|---|---|---|
| By email | You know which email the person signed up with. | Their account's exact email. |
| By phone | They're already in your contacts and turned on "let others find me by phone". | Just the number — the app finds the account and shows the name before you send. |
| By code | You don't know the email, or don't even know whether they have an account. | Nothing. The invitation stays open and you send the code in a message. |
By phone
The lookup only finds people who turned the option on under Sharing > Let others find me by phone and entered their own number. A number nobody declared is answered exactly like a number that belongs to no account.
What the lookup returns is the name and email of the account found, for you to check before sharing — and it is that account the share is created against. So check the name; and on the other side, an unexpected invitation is simply declined.
Turning the option on does not publish your number: it is never shown to anyone, never returned by a search, and only lets someone who already has it in their contacts find your account. You can turn it off whenever you like — clear the number and save — and from then on nobody finds you by it.
Confirming the number is yours
When you save a number, the app may ask you to confirm it: you get a code at that number and type it on the same screen. While a code is outstanding the number field is locked — the code belongs to the number it was sent to, and changing one underneath the other would leave the two talking about different things. You can ask for another code, and you can cancel; cancelling leaves your account's number as it was.
Whether there is a code at all is the server's call, and it answers that on every request — so the screen tells you before you save that the confirmation is coming, and which way the code will arrive. Where confirmation is not switched on, the number is stored as declared, and it is worth knowing what that means: nothing proves it belongs to whoever typed it. That is why the invitation still depends on your acceptance, and why a number can only be on one account at a time — first to declare it keeps it. A number that has been confirmed is shown as such on the screen.
By code
An open invitation has no recipient: the server issues an 8-character code and you send it through whatever messaging app you already use with that person — the Send invitation button opens the system share sheet with a ready-made text carrying the link and the code.
On the other side there are two routes:
- They already have the app: they enter the code under Sharing > I have a code. The invitation becomes theirs and shows up in their received invitations, to accept or decline.
- They open the link: it lands on a page on the website showing which category the invitation is for and who it is from. If they have an account, they sign in and answer right there. If not, the page explains that sharing depends on a synced account and offers to create one — or to decline, and you find out.
While nobody has redeemed it, the share shows on your side as "waiting for the code to be redeemed". As soon as someone redeems it, the invitation stops being open: the code no longer works and the list shows the name of whoever took it. A code is good for 14 days, and each category may have up to three open invitations at a time.
Whoever holds the code becomes the recipient of the invitation — it is a key sent in a message. Send it to the right person and avoid groups. If it went to the wrong place, revoke the invitation before anyone redeems it.
The lifecycle of a share
- You create the invitation. You pick the category, point at the person (email, phone or code) and the access level. Nothing happens immediately: the invitation sits "waiting to sync".
- The sync carries the invitation. The server is what validates the recipient and sends the notice — or, for an open invitation, issues the code. If the person doesn't have an account yet, they get an email inviting them to create one.
- The person accepts or declines. On their side, the invitation shows as pending. On accepting, that same sync already starts bringing the category's content in.
- The content arrives gradually. The screen shows counts of received categories, entries and annotations, and they grow with each sync until the history is complete.
Ending a share
- Revoke — (owner) removes the access. The other person's device cleans up on its next sync.
- Delete — (owner) removes the share entirely, including the invitation record.
- Decline / leave — (guest) declines a pending invitation or leaves an accepted one. The shared category and its data leave that device.
What gets locked while the share exists
On the owner's side, the app blocks moves that would change who is inside the shared branch. Moving a category into it would expose content the guest was never meant to see; moving one out would leave permanent copies on their device, with no way to erase them. So both are blocked, with a message naming the share that caused it.
- Moving the whole shared branch (by its root or an ancestor) is still allowed — that doesn't change who is inside.
- Deleting a category that intersects the shared branch is blocked too.
- A category that reached you through a share cannot be re-shared onward.
- Reordering among siblings is never blocked, on either side: order is how the person looking arranges things, not structure.
An entry split between a shared category and a non-shared one would arrive halved on the other side — and the total wouldn't add up. So the app refuses to create the share when splits cross that boundary, and blocks new splits that would cross it. If creation is refused for this reason, resolve the splits first and try again.