This page is about the Dashboard screen. For what a level is, which direction
a read travels, and what you can reach today, read Scope
ladder first.
One ladder for the whole account
Your ladder belongs to your account, not to an instance. Every instance you run shares the same levels, and there is no way to give two instances different ones. That is deliberate, and it follows from how people and organisations are identified. A customer id means the same customer everywhere in your account, and a user id means the same person, whichever instance sent the request. Two instances writing about customeracme are writing about one customer, not two.
If those instances disagreed about what the levels are, the same records would
be filed under different level names depending on which instance wrote them, and
a read from one instance would not find what the other stored. Your memory would
split in half with nothing to tell you it had.
Your instances still keep their own memory settings. What they cannot keep is
their own ladder.
The one part of this that IS per instance is the switch. Nested scoping can be
on for one instance and off for another, which is what makes a careful rollout
possible: turn it on for a test instance, watch it, then turn it on for the
rest. The shape is shared; when each instance starts using it is not.
Reading your ladder
The main panel lists your levels in order, top rung first, indented so the nesting reads as nesting. Each row shows three things:- the name, which is what you call that level
- the key in small type beside it, which is what stored memories resolve through
- how many entries are filed at that level right now
customer_id and user_id, so a call has to name it in a scope path instead.
- needs a scope path means your traffic is already on an SDK that can send one. Name the level in the path and you can read and write at it.
- needs SDK 0.4.6+ means we have not seen a capable SDK in your recent requests. Upgrade, then the level becomes reachable.
Two banners worth reading
Above the list, the page states two things that are easy to assume and easy to get wrong. Whether the ladder has been accepted. An unaccepted ladder is a draft. Nobody has agreed to it, so your account is still filing and reading memories the default way and nothing on the page is affecting your data. Once someone accepts, the banner names who accepted it and when. Whether nested scoping is switched on. A ladder can exist while nothing uses it, which looks configured and behaves exactly as it did before. The banner says which of the two you are in: off, on for all your instances, or on for some number of them with the rest still reading the previous way.Renaming a level
Type a new name in any row and a bar appears with Save names. Only the rows you actually edited are sent, so an untouched level keeps its name and the audit line does not claim you renamed something you left alone.What we suggest, and why
Lower down, a panel shows the ladder Synap would suggest for your account, read out of your use-case document. Every rung carries the reason it was proposed and quotes the line in your document it came from, so you can judge the reasoning instead of taking it on trust. Where the suggestion is unsure, it says so. Anything Synap is not confident about is listed under things we were not sure about as a question, rather than added to your ladder. A level decides who can read whose memories, so it is never inferred from prose that did not ask for one. If your use-case document did not say how your users are grouped, the panel says that plainly and shows the standard three rungs instead of a shape invented for you.Every account is given a ladder at signup, so most of the time this panel is
advisory only and the thing you can act on is a rename: it offers to call your
existing levels what it suggests calling them. Accepting a whole ladder only
appears for an account that has none.
Accepting a ladder
If your account has no ladder, the same panel becomes actionable. You can retype any name you disagree with first, then use Use this ladder. Accepting creates the levels and records who accepted and when. It does not move any memory you have already stored, and it does not switch nested scoping on by itself. Renaming stays free afterwards. Removing does not: a level can never be deleted once it exists, only retired.Adding a level
Add a level opens the only control on the page that moves stored records, so it is the only one that will not act on a single click.1
Name it and say what it is for
You give the level a name, such as Team or Branch or Region, and one line
describing what it holds. The permanent key is derived from the name and
shown to you, so you are not asked to invent a stable identifier for a thing
you are still naming.
2
Choose where it goes
Pick which existing level the new one sits above. A new level has to land
between two existing ones, so on the standard ladder that means above
Customer or above User. Adding one re-files everything currently beneath
that point.The list also offers a position at the very bottom, under your last level.
Do not use it. Nothing is allowed to sit below the level that identifies a
person, so that choice is refused when you commit it.
3
Preview changes
Before anything happens, the page tells you how many entries and how many
memories inserting the level there would re-file, and what your levels would
read as afterwards. Nothing has changed at this point.
4
Add this level
The commit carries back the same number you were shown. If your structure
changed while you were reading the preview, the change is refused rather
than applied against a count nobody saw.
Checking a request
Check a request lets you stand somewhere on the ladder and see what you can see. Enter the customer id and user id your application would send, and the page shows the chain of levels that request reads from, in order. It previews only. Nothing is created and nothing is changed by typing here, so checking an id that does not exist yet will not quietly register it. If the ids do not resolve, the panel says so and explains why rather than returning an empty chain. If nested scoping is off for that instance, it tells you the chain is the shape you would get once it is switched on.Coverage
A panel near the bottom compares how many of your groups are on the ladder against how many exist. When they match, it says so in one line. When they do not, it reports the number of memories sitting in groups Synap has no record of creating. Those cannot be placed automatically, and re-running a backfill will not change it. The number is stated as a count of memories rather than a percentage, because a small percentage of a large account is still a lot of memories.What this page will not do
Being clear about this is more useful than making the page sound finished.Next steps
Scope ladder
What a level is, which direction a read travels, and where your ladder came
from.
Identifiers & Scopes
What
customer_id and user_id do on every request.