Announcing our public release & a free multi-chain wallet adapter! 🎉
Table of contents
Let’s say you want to manage an invite-only beta for your web3 project, with Airtable being your source of truth CRM, where you control who (and which wallets) has access to your beta. What should you do?
Well.. you can easily do it with Dynamic and Airtable. Let’s take a look at how.
Note: In this guide, it is assumed that basic authentication with Dynamic has already been set up, but if not, it can be done in a few minutes by following the getting started guide.
To start, we’ll create a basic Airtable table that has a few fields. In your base, create a new table and name it Access list, and add the following fields:
Now that we have a basic CRM ready, let’s generate a new form to allow customers to sign up for the beta. You can do so by going to views -> create -> form.
Note: We do not surface the `Allow` and `DynamicID` fields which are only used internally.
Great. Now we have a CRM and an in-bound form, and we're done with our basic Airtable setup.
Now that we have a basic CRM going, let’s turn to configuration within Dynamic.
Dynamic is a full web3 authentication and authorization system. With Dynamic’s user management setup, you can quickly add additional authorization functions, such as access list control and NFT gating, without the need to implement separate access management tools, as they can simply be enabled in seconds.
In your Dynamic dashboard, click on Access list, and click to Create a new list.
Within the Create list modal, define a name for your list (we called ours Airtable) and click Create new list.
Now we have an Access list set up. When we add wallet addresses to the list, Dynamic will automatically allow their entry, blocking all other wallets from being able to log in.
You will be able to grab your Access list ID from this screen as well, which you’ll need later on in the process.
Our next step is to generate an API token so that we can programmatically update the list. Go to API within your developer dashboard, and click to Create token.
Now that we're done with the setup on the Dynamic site, we'll go back to Airtable to set up our automation. Click on the Automation tab, and select the option to trigger an automation when a record matches a condition. We'll set it up so that when a record is marked as "allowed", the automation will be triggered.
Once these are defined, we can use the following script to post the update to Dynamic, mapping the submitter name into an alias, as well as the wallet address.
At this point, you can run a quick test to make sure things work well. The Allow list should now update in Dynamic when something changes in Airtable.
Now, let’s write back the ID response back to Airtable so that we can reference it in the future. We'll do so by updating the DynamicID entry of the referenced row we added to the Allow list.
That's it! You should now be able to check anyone in your CRM that you'd like to add to the Dynamic Allow list . Within a few seconds, the Dynamic ID will appear, referencing the entry, and allowing you to make changes in the future.
For this demo, we added two entries of customers that need (and deserve) access:
In the spirit of being nimble, I turned to ChatGPT with some scripting help. With a quick prompt ask, ChatGPT generated a basic version of the script I needed in step 3 above.
Now that we have a working version of the flow, there are several ways to extend and optimize it, which we won’t cover here. However, here are a few ideas for how to further improve the script:
Share this article
(Oh, and we also offer a free multi-chain wallet adapter)