If I change this default, what else is going to change?

You turn a workspace's notification default from On to Off and a week later, one project is still sending notifications. My first thought would be that the change hadn't worked.

But then you get into what that On actually meant. You find that one project might have its own On setting, another might only be On because it's following the workspace, and a third could be locked On by an organisation policy. The workspace change can work exactly as designed while that first project keeps sending notifications.

Before the change they all just looked On and you could see the current value, but not where it had come from, so there was no way to tell which projects would change with the workspace and which ones would carry on doing their own thing.

Matching the default is not the same as inheriting it

You've probably seen a smaller version of this in browser permissions. Chrome has defaults for things such as camera, microphone and notifications, but a site can have its own permission instead. It also gives you Reset permissions, and that isn't just another way of choosing whatever the browser default happens to be today. It removes the site's exception so the site follows the browser default again.

So a project can have its own value and still happen to match the workspace today. Choosing On again doesn't put it back under the workspace, it just saves another local On.

The value tells me what the setting is now and its source tells me what will happen when the parent changes.

Once the source sits beside the value, Reset to workspace makes sense too. It isn't setting the project to whatever the workspace happens to say today. It is removing the exception so the project follows the workspace again.

Azure SRE Agent does this in a smaller way. Its agent cards label settings as Inherited or Custom, then the settings page explains which changes apply only to the default agent.

And if a row is locked, I want the same principle to go further. Don't just show me a disabled toggle, actually show me that the real control lives somewhere else and give me a way to get there.

Show what will move before they save it

Fixing the project row gets us part of the way, but I would still want the workspace screen to tell me what this change is going to do before I save it. If seven projects will follow the new value, two have their own setting and one is controlled by policy, put that beside the parent toggle.

An important part of this is showing what will move and what will not while the person can still inspect the change.

I wouldn't put this on every preference, obviously that can be overkill and this is just an example to get you thinking about the problem and the changes you can make in your own interfaces. It matters when a value can come from somewhere else: a workspace, another parent or a policy. And a custom value isn't automatically wrong just because it differs from the parent. The main point is to make the relationship visible, not to eliminate exceptions.

So when I review a settings screen like this, I don't stop at whether the toggle shows the right value. I change the parent and ask: what follows, what stays put, and can I tell why?

If I need the documentation or the data model to answer that, the value on screen might be right, but the interface is still hiding what my change is going to do.