> ## Documentation Index
> Fetch the complete documentation index at: https://docs.synclify.cloud/llms.txt
> Use this file to discover all available pages before exploring further.
# Security settings
> Password, two-factor authentication, review policy, kill switches, and support access.
**Settings → Security** holds the controls you operate. It is not the same page as [Security](/security), which describes how Synclify handles your data and credentials.
What you find here depends on your role — some cards are owner-only.
## Change password
> Change the password you sign in with. Changing it signs out every other session.
Enter your current password, then the new one twice. Minimum **12 characters**. If you have only ever signed in with a link or with Google, leave the current-password field empty — it says *"Leave empty if you never set one."*
*"Check your current password and try again."*
The new password was rejected by policy. *"Choose a password of at least 12 characters."*
The confirmation field differs from the new password.
Changing your password signs out **every other session**. That is the point: it is also how you evict a session you no longer control.
## Two-factor authentication
> Require a code from an authenticator app on every sign-in — password and emailed link alike.
Note "and emailed link alike": turning this on closes the gap where someone with access to your inbox could sign in without your password.
Scan the QR code with your authenticator app, or type the **manual entry secret**.
Enter the current 6-digit code to prove enrollment worked.
*"Save these recovery codes now — they are shown only once."* **Copy codes**, store them somewhere that is not the device running your authenticator, then click **I saved them**.
The status row then reads **On**, with how many recovery codes are left.
Turning it off needs *"a current authenticator code or an unused recovery code"*. If the code is rejected: *"That code didn't work — Enter a current authenticator code or an unused recovery code."*
Recovery codes are shown **once** and each works **once**. Lose both your authenticator and your codes and you will need support to get back in.
## Review before changes go live
Owner-only. It decides whether a connection can be activated by the same person who set it up.
**A second owner or admin must approve.** *"The person who edits a connection cannot be the one who activates it."*
Use this when a bad activation would be expensive — client sites, large collections, anything with delete propagation on.
**Anyone who can edit can approve.** *"Faster for solo workspaces and small teams. Every activation is still recorded."*
This is the default, and it is a reasonable one. Recording is not the same as blocking, but it does mean nothing is anonymous.
Turning it on is disabled until there is somebody to do the reviewing: *"Invite a second owner or admin to enable two-person review."*
## Workspace kill switches
> Emergency stops for this workspace's syncing. Engaging one requires a reason and is recorded in the audit log.
Available to **owners, admins, and support**.
| Switch | What it blocks |
| --------------------------- | -------------------------------------------------------------------------------------------------------- |
| **Pause all syncing** | *"Blocks every new sync run and cancels runs already in flight. The big red button."* |
| **Pause automatic syncing** | *"Blocks webhook-triggered runs. Manual and scheduled syncs keep working."* |
| **Pause reverse syncing** | *"Blocks any run that writes back to your source (reverse, bidirectional, destination reconciliation)."* |
**Engage** asks *"Why are you engaging this? (required)"* and then **Engage switch**. An engaged switch shows its reason and the time it was engaged. **Release** lifts it.
Releasing a switch does not replay what it blocked: *"Blocked runs stay stopped — trigger them again if needed."* After a **Pause all syncing**, check the connections that should have synced meanwhile.
A switch can also carry a **Disabled platform-wide** badge, which means it is off at the platform level and not something your workspace controls.
**Pause reverse syncing** is the surgical one. If a bad edit is propagating from Webflow back into your source, it stops the damage while leaving normal source-to-Webflow syncing alive.
## Support access
Support cannot open your workspace unless you let them. Visible to **owners and admins**.
> Everything a support agent looked at or changed in this workspace, newest first. Recorded automatically and kept for your audit history.
Enter the support agent's email and answer *"What do you need help with? (required)"*.
**24** or **72 hours** by default. The button reads **Allow for N hours**.
*"*{agent} *can help until* {time}*. It ends on its own."* You do not have to remember to revoke it.
While a grant is live, an amber card names who can open the workspace, the reason you gave, when it ends, and **· not opened yet** until they first use it. **End access** revokes it immediately: *"Support can no longer open this workspace."*
### The trail
Every action a support agent takes is listed in plain language — "Viewed the job queue", "Paused Blog → Posts" — with who did it, when, and a **Change** badge on anything that altered state. Repeated actions collapse with a count.
This is why **Support** is not an invitable [role](/account/team#roles). Support access is always a time-boxed grant with a stated reason and a full record — never a standing seat on your team.