Auth Plugin's Access Switch: Real Properties, the 4 Mode Values, and When to Use It Over Code Overrides

• Access Switch's real properties panel has a Mode dropdown with four confirmed values: Authenticated (auth), Grant ID (grant), Label Name (label), and Tier Level (tier).
• Locked Layer and Unlocked Layer are dropdowns that pick from named layers already on the current Framer page, they are not fixed built-in options.
• The components page describes Access Switch as checking auth state or grant ownership, that's accurate but only covers two of the four real modes.
• Access Switch swaps between two fully designed layers; Code Overrides toggles visibility on a single element instead.
• What a Grant ID, Label, or Tier value actually gets set to isn't confirmed by anything checked for this post, that detail isn't guessed at here.

Access Switch is a real, confirmed Auth Plugin component. It appears in the Framer insert panel with the description "Show/hide content based on auth state," and it's named on the marketing components page, quoted later in this post. Everything below is confirmed against that live properties panel and the canvas.

In Framer's insert panel, Access Switch's label reads "Access Switch," with the description "Show/hide content based on auth state." Drop an instance onto the canvas before connecting anything, and it renders as a placeholder block with a lock icon, reading "Connect Locked & Unlocked layers" with "Mode: auth" underneath, telling you exactly what it needs: two layers to swap between, and a mode to decide which one shows.

Unlike a component that just hides or reveals one element, Access Switch is built around two separate, fully designed states, a locked one and an unlocked one, and it picks which one renders based on Mode.

The Mode property is a dropdown, and its own helper text spells out the whole set in one line: "How to determine access. 'auth' = any logged-in user, 'grant' = specific permission, 'label' = user label, 'tier' = minimum tier." Broken out, the four values are:

• Authenticated: "'auth' = any logged-in user." The simplest check, is anyone signed in at all, with no permission, label, or tier involved.
• Grant ID: "'grant' = specific permission." This checks for a specific permission grant rather than just login state.
• Label Name: "'label' = user label." This checks against a user label rather than a login state or a specific grant.
• Tier Level: "'tier' = minimum tier." This checks that a user meets some minimum tier rather than a simple yes/no on login.

Worth being plain about what isn't confirmed: nothing checked for this post shows what a Grant ID, Label, or Tier value actually gets set to, or whether a separate settings page elsewhere in Auth Plugin defines grants, labels, or tiers. Treat Grant ID, Label Name, and Tier Level as real, distinct Mode options with confirmed helper text, and nothing more specific than that.

Below Mode, the properties panel has two more fields:

• Locked Layer: a dropdown, description "Layer shown when user does NOT have access."
• Unlocked Layer: a dropdown, description "Layer shown when user HAS access."

Both are layer pickers. They list whatever named layers already exist on the current Framer page, not a fixed menu of built-in options. In practice, that means you design two states yourself first, a locked view (a paywall message, a blurred preview, a "sign in to continue" prompt) and an unlocked view (the real content), name those layers, then point Locked Layer and Unlocked Layer at them from the dropdowns.

That's the meaningful difference from a simple show/hide toggle. Five other Auth Plugin components, Social Auth Button, Sign Out Button, Sign In Form, Avatar, and Identity Label, ship a built-in self-hiding toggle: set one Yes/No property and the component removes itself for a signed-out visitor. Access Switch works differently. There's no single toggle, it holds two independently designed layers and switches which one appears based on which of the four Mode values you've picked. Get the access check wrong and a visitor sees the wrong layer, not a missing element.

The components page describes Access Switch as: "Shows or hides child content based on authentication state or grant ownership." That's accurate, it correctly names auth and grant. It just doesn't mention label or tier, which are just as real in the Mode dropdown. Nothing's wrong with that line, it's simply a shorter summary than the full properties panel supports.

Auth Plugin's pricing page lists "Advanced access control" as a real feature on the Pro plan. Nothing in Auth Plugin's documentation explicitly ties Access Switch's Grant ID, Label Name, and Tier Level modes to that line item, but it's a reasonable inference. A simple auth check (logged in or not) is the kind of thing a free or basic tier typically handles. Grant, label, and tier modes go further, toward role- or plan-based access rather than a binary logged-in/guest split, which lines up with what "advanced access control" would mean. Read this as a plausible connection, not a confirmed one.

Auth Plugin already has a general-purpose way to show or hide content by login state: Code Overrides, with its ShowWhenAuthenticated and ShowWhenGuest overrides that apply to any single Framer element. Access Switch isn't a replacement for that, it solves a different shape of problem.

Reach for Code Overrides when:

• You need to toggle visibility on one existing element, a button, a text layer, a section, without designing a second version of it.
• A simple authenticated/guest check is all you need, nothing role- or plan-based.
• You're already applying IdentityName, IdentityEmail, or TriggerSignOut nearby and want the visibility logic to live in the same file.

Reach for Access Switch when:

• You need two distinct, fully designed states, not just one element appearing or disappearing, a locked view and an unlocked view that each look intentionally different.
• The access check itself needs to be more than logged-in/logged-out, Grant ID, Label Name, or Tier Level cover cases a binary check can't.
• You'd rather manage the swap as one component with two connected layers than juggle two separately overridden elements sitting in the same spot.

The gating guide already frames Access Switch as the right tool for gating a section within an otherwise public page, this post adds the mode-level detail behind that. Neither component is "better," they answer different questions: Code Overrides asks "should this one thing show right now," Access Switch asks "which of these two designed states should show, and by what rule."

There's a third point of comparison worth making: Protected Pages gates an entire page at the URL level, matching the route itself and blocking the whole page if a visitor doesn't qualify. Access Switch works inside a page that's otherwise reachable, and its four Mode values give it finer, mode-based control over what renders in that one spot than a page-level rule can offer. Use Protected Pages to lock down a route, Access Switch to control a section within a page everyone can load.

• Assuming Locked Layer and Unlocked Layer offer built-in preset options. They don't. They list whatever named layers already exist on the page, so the locked and unlocked designs have to be built and named first.
• Leaving Mode on auth when a role- or plan-based check was actually needed. Authenticated only checks whether someone's logged in at all, it has no idea about grants, labels, or tiers.
• Guessing at what Grant ID, Label Name, or Tier Level actually check without testing. These are real, distinct Mode options, confirmed by their own helper text, but what specific value each one resolves to depends on your own project setup. Verify it directly in your instance rather than assuming.
• Reaching for Access Switch to hide one simple element. If there's no second designed state to swap in, Code Overrides' ShowWhenAuthenticated or ShowWhenGuest is the more direct tool.
• Assuming grant, label, and tier values are defined somewhere specific without checking. That configuration, if it exists, wasn't part of what's confirmed here. Don't guess at where those values come from.

What are the four Mode values on Access Switch?
Authenticated (auth, any logged-in user), Grant ID (grant, specific permission), Label Name (label, user label), and Tier Level (tier, minimum tier), per the properties panel's own helper text.

Do Locked Layer and Unlocked Layer come with preset layer options?
No. Both are dropdowns that list whatever named layers already exist on the current Framer page. There's no fixed, built-in list.

Does the components page description of Access Switch cover all four modes?
No. It describes auth and grant ownership specifically. Label and tier modes are just as real in the properties panel, the marketing line is just shorter than the full feature set.

Is Access Switch's Grant ID, Label Name, or Tier Level connected to a confirmed pricing feature?
Not explicitly. Auth Plugin's pricing page lists "Advanced access control" on the Pro plan, and these three modes look like a plausible mechanism for that, but that connection isn't stated anywhere in Auth Plugin's own documentation.

Should I use Access Switch or Code Overrides to hide a single button from guests?
Code Overrides. Its ShowWhenGuest and ShowWhenAuthenticated overrides handle a single element directly. Access Switch is built for swapping between two fully designed layers.

Where do I define what a Grant ID, Label, or Tier value actually is?
That isn't confirmed by anything checked for this post. If a separate settings area exists for defining grants, labels, or tiers, it wasn't part of the verified properties panel or canvas behavior described here.

Access Switch's real properties panel has three parts: a Mode dropdown with four confirmed values (auth, grant, label, tier), and Locked Layer and Unlocked Layer dropdowns that pick from named layers already on the page rather than offering built-in presets. The components page's "authentication state or grant ownership" description is accurate but only names two of those four modes. Reach for Access Switch over Code Overrides when a build needs two distinct, fully designed states rather than one element toggling visibility, or when the access check needs to go beyond a simple logged-in/guest split. What exactly a Grant ID, Label, or Tier value resolves to isn't confirmed here, and it's better to say that plainly than to guess.