Is it possible to link the subscription of a user from strip to the user record in airtable?

My product needs to be able to identify the subscription level of the user in airtable so that we can supply services at the level of subscription that each user has paid for.

For example, a user with a “basic” subscription can make 10 requests a month. In order to limit the user to 10 requests a month we need to be able to see in airtable that the requests we’re recording are from a user w/ a basic subscription.

Is there any way to pipe that data into my user record? And to be clear I don’t want to store any payment details… strictly the “product” as labelled in stripe as a column.

A secondary question would be… is it possible to somehow connect the “user” group that a user is in to the user record?

I basically just need some way to sort/filter my users in airtable off of the subscription level they are currently at. Not seeing a way to do it w/ user groups, stripe checkout, or the simple billing block.

No, Softr doesn’t expose any information about a user’s products or subscription in Airtable.

The workaround is in your Airtable base to count the number of requests a user has made, then in a formula column to the range the user is in (ex: 0-9 requests, 10-19 requests, etc., and then configure user groups for users that haven’t and have reached their limit.

Example User Groups:

  • Uses with Request Limit Not Reached. Criteria: Range field = 0-9 requests
  • Users with Request Limit Reached. Criteria: Range field = 10-19 requests

If you have a block with an “Add Requests” button, do two copies of the that block (or, at the least the button), one that works for Uses with Request Limit Not Reached user group, and the one for Users with Request Limit Reached user group that takes the user to the pricing page to upgrade to get more requests.

You can always use Zapier or Make to get subscription changes from Stripe and push to Airtable, but in order to enforce request limits, you’ll need the above solution regardless.

Awesome going to try today! Thanks a ton for the direction here. I was spinning my wheels trying to use linked records in airtable and other crazy dead ends :slight_smile: :frowning:

Resurrecting this thread @rrthegefsrht. Can you expand on that solution you shared?

Currently I have a table where all the requests go. Would you add the formula column to that same table or would you add the formula column to the users table and have the value update based on what the formula can see in the other table where requests are?

What I’m hoping to do is:

  1. Add formula column to user table
  2. Formula column has two values that can be set: Limit Reached, Limit Not Reached.
  3. Formula will count number of requests, by user, within current month.
  4. IF number of requests, by user, within current month = user limit | return value of Limit Reached
  5. IF number of requests, by user, within current month = < user limit | return value of Limit Not Reached

Then separately in Softr, if the above can work, I should be able to create both of the user groups you recommended based on the conditions of: Visible if Logged in user’s {Limit Field Name} is {Limit Reached} or {Limit Not Reached}

^Is this what you’re saying?

If that’s an accurate summary… any resources on how I can write formulas in airtable?

@jzuilkowski unless you’re using Zapier or Make to get subscription info from Stripe, you can’t actually use Airtable to calculate if a user is under/over their subscription limit.

Assuming you have this data, the formula should be pretty straightforward, so let’s focus on the formula assuming you don’t.

The way that I approached this was by setting a quantity of something (say, coins added to a collection) per subscription level.

Level 1: Collect up to 25 coins
Level 2: Collect up to 50 coins
Etc.

The way that you setup your formulas is:

On your users table, count the number of linked records for collected coins that are linked to the user.

Then, in another column, use a formula to bucket which tier their usage is in using nested IF formulas.

IF( {Count of Collected Coins} >= 0 AND {Count of Collected Coins} <=24, “0-24”,
IF( {Count of Collected Coins} >= 25 AND {Count of Collected Coins} <=49, “25-49”,
IF( {Count of Collected Coins} >= 50 AND {Count of Collected Coins} <=74, “50-74”,
Etc.

Then, in Softr, setup lots of user groups (this part was painful for me personally - I have over 100 user groups, lol). Example:

Tier 1 Subscription Under Limit: Criteria is Subscription = Tier 1 and Count of Collected Coins = 0-24
Tier 1 Subscription Over Limit: Criteria is Subscription = Tier 1 and Count of Collected Coins = 25-49 or 50-74
Tier 2 Subscription Under Limit: Criteria is Subscription = Tier 2 and Count of Collected Coins = 0-24 or 25-49
Tier 2 Subscription Over Limit: Criteria is Subscription = Tier 2 and Count of Collected Coins = 50-74

Why do you need so many user groups?

You’ll want to create dup copies of your blocks and make them visible to user groups that are for under/over limit users.

If block is for under limit user groups = The “Add” buttons (or whatever buttons you use) work
If block is for over limit user groups = Keep the “Add” buttons, but redirect users to the pricing page to upgrade because they’re at their plan limit

If you’re paying for a higher tier Sofr plan with button visibility you can probably get away with setting visibility at the button level instead of the block level and not having dup blocks, but this is the cost effective way to do it while your app is still growing.