I may be a victim of my own automations. Please help me understand the expected behavior
My app is a project management tool, where I assign user (customers) into projects.
To live within the confines of my allowed user limit (100) I deactivate users that are associated with project that have been completed and the customer no longer needs access. This is achieve by calculating the number of days since login, when the number is greater than 90, airtable sets the user status field to “inactive”. I use a sync rule in softr to only sync user that are not inactive, and when a user is no longer sync’ing they get deactivated in softr. Shown below
Occasionally a customer returns for another project so I reactivate them in the softr studio UI. This results in a new user sync’ing into airtable as shows below:
The first user was created Nov 2025, and the new user is created in Jun 2026.
The original user is the only user linked to any project. I should also mention that the linking of the user to the project is done by a different zapier automation that comes from my CRM, which looks for the user by email address and assigns them into the project.
In the example we are looking at here the project was created and user assigned first, THEN the softr user was reactivated, resulting in the duplicate user in the airtable.
The reality is that all of this just “worked” even though there are two user entries in my aitable (which I don’t like seeing).
Since the airtable “deactivation process” if driven by formulas, I cannot simply change the user to “active” in airtable. But if I could, would that restart the sync to Softr if that user has been deactivated in softr? and would that stop duplicate user from getting created?
The behavior points to two competing sources of truth: Airtable still says the original record should not sync, while the Softr UI is being used to reactivate the account. I would make Airtable authoritative for both deactivation and reactivation.
A safer lifecycle is:
-
In the advanced user-sync settings, choose Deactivate when a record stops matching the sync rule, not Delete or Unsync. Softr documents that deactivation retains both records, removes the user from the plan count, and allows the same user to reactivate automatically when the sync rules match again.
-
Add one writable Airtable field such as Access override or Access state. Keep your formula, but make the final Should sync formula true when the user has an active project, the override is Active, or the inactivity threshold has not been reached. That avoids trying to edit a formula result directly.
-
When a returning project is created, have Zapier find the existing Airtable user by a normalized email address, update that record, and set the access field to Active before doing anything in Softr. The no-match branch may create a user; the match branch should only update.
-
Let the sync rule reactivate the existing Softr user. Do not manually reactivate the Softr account first while its Airtable row is still excluded, because that recreates the mismatch that appears to be producing the second row.
-
For the duplicates already present, pick the original project-linked Airtable row as canonical, repoint any links from the newer row, test one account, and only then remove the duplicate. Export the two rows first so the Softr user ID, email, and project links are recoverable.
The current Softr sync documentation describes the Deactivate behavior here: Syncing users with a data source – Softr Help Docs
The one setting that will confirm this path is: under Advanced sync, what is currently selected when a user stops matching the filter — Deactivate, Delete, or Unsync?
Disclosure: TinyOps Studio LLC maps Softr/Airtable lifecycle automations. If you want the sync rule and Zapier branches reviewed against screenshots before changing production, the fixed-scope triage is $49: https://whop.com/joined/tinyops-studio-llc/products/quick-workflow-triage/
