Help understanding user sync rules

Ask the community
1

Hello, I am trying to manage my active users so I can stay within my softr subscription limits. Based on other post in the features requests section I am testing conditional user syncs with auto deactivation. But I am concerned my logic is flawed and am hoping someone can help me better understand and course correct if needed.

My desired logic is that is a user is inactive for 90 days they will be deactivated in softr so I can reclaim that user “license”

My users originate in an airtable and are sync’d into softr, previously using the “all” setting in softr user sync. “last seen” dates from softr are sync’d inot the airtable, so I created two new fields to determine activity:

  1. “Days inactive” counts he days between the last seen date and today
  2. “User Status” uses a formula to set the status depending on the number of day in the previous field
  • Equal or Greater than 90 = “Inactive”
  • Equal or less than 89 = “Active”
  • No last seen date = “Never logged in”

Here is where things go sideways…

The softr “auto-deactivation” is based on whether a currently sync’d user ceased to be sync’d. So using the airtable information previously mentioned, I create a sync rule that says “only sync users that are NOT “inactive” (using the airtable “user status” field). Softr documentation says:

image
image1288×383 62 KB

Let’s assume this is working as expected. What happens when I manually re-activate a user in softr (which I just tried). The user still shows in softr user management no longer being sync’d even though I have re-activated their softr account. The source data hasn’t been updated to reset their log in counter or status, so the current state still meets the sync rules to NOT sync this user.

So how is this re-activation supposed to work?

If I change the logic to begin the reactivation “process” in the airtable data, and manually set the user status to “active” that would theoretically start sync’ing the user in softr, but what would trigger softr to “re-activate” the user?

Furthermore softr doesn’t sync “activation” data into the data source which just adds another layer of confusion when trying to operate solely in the data source.

2

Please note that when you enable filtered user sync, users become deactivated and are no longer synced when they stop meeting the conditional filter defined in your sync settings.

You can still manually reactivate them from the Users section of your app. However, this only reactivates their account, they still do not meet the sync conditions and will not be synced unless the values in your database are updated so that they match the defined conditions again.

In the example shown in the screenshot below, I only sync users whose Role field contains either “Admin” or “Client”. If I remove the “Admin” value for a user in my database, that user will no longer be synced and will be deactivated in the app according to the configuration.

I can manually reactivate their account from Softr so they can access the app again, but they will still have an empty or non-matching value in the Role field. This means they will not meet the sync conditions. They will only be synced again if I add back “Admin” or “Client” to the Role field in the database.

image
image1920×974 114 KB

3

Yes, this answer aligns with my understanding and leaves the workflow as incomplete.

I can build the logic on the airtable side to essentially re-activate the user to meet the sync rules, but the airtable data is still operating blind as it doesn’t get the “status” from the softr user data.

If I build the logic in airtable to handle this I would much prefer for airtable to also own the decision for who is active or not. So airtable can calculate that a user is “inactive” and set the softr status field to “deactivated”, then send that into softr.

What I need is softr status to be sync’d out to airtable and accept sync’d value back in from airtable.