Hello All! I am trying to allow a parent to sign up for their account in my app. They enter up to 4 other email addresses where all of those users should be sent a magic link to sign in, with all of these accounts sharing the same data. The issues I’m having is that using softr’s sign up block, it always navigates to the /home page and I need it to navigate to another page, for the user to input the children’s emails. I’m also not sure if it’s best to generate one magic link for everyone or one magic link for each person’s account. Any insight is appreciated.
Would page rules help you with the redirect?
Yes, I’m not sure how i missed that! thank you Mark!
currently, I get the parent to sign up in a softr sign up block, then add their children’s email addresses in a regular form, so they don’t get a magic link. Do you think it’s practical to use one magic link for all of the accounts and limit each user’s data using filters, or is it a better practice to generate a new magic link for each of their children?
Personally, I would have each user having a unique email address and unique Magic Link. This will give you maximal flexibility and options as you move forwards with developing your app. You never know when you might need to create separate user groups for parents and children; also personalised information unique to any user.
Is there a way to generate a magic link and submit it as a hidden field in a form? I don’t see them as an option in the dropdown, but should this be done with custom code or something?
I appreciate your replies Mark!
I use Zapier to handle Airtable-Softr connections to trigger Magic Links to be generated by Softr and passed back to Airtable.
ok I will check that out. Thank you!
I know this is an old post, but in case it helps anyone in the future when it comes to having multiple users within an organization, each with their own magic link, here’s how I do it. But I’ll also explain how to make it such that you can create an enterprise-level setup with role-based access, then department-level groups under that, also with its own role-based access and magic link for each user. (I’ll make this explanation highly detailed, but it’s really not as complicated as it sounds or will look based upon the wall of text this will be.)
Tool Setup:
I use Airtable for my data source, and most forms are done using Fillout, though I do use Softr’s forms in some instances. We have clients and then users under those clients. Each client is assigned a client code at the time their record is created. This code is used in a variety of ways, but it’s really key in tying all users to a particular client through linked tables.
The users, meanwhile, fall in one of three categories: Primary Administrator, Additional Administrator, and General User. The roles determine visibility of fields/forms/pages/navigation options, etc., and are tracked in a user record via a single-select field named “User Role”. The primary and additional administrators function almost identically, but only the primary administrator can edit the company’s key profile data (address, tax ID #, etc.). Both types of administrators can add additional administrators or general users.
Use Case:
I own a corporate gifting company. For larger clients, there’s usually one department that’s responsible for their company’s account with us. That typically falls to the marketing department, so I’ll go with that for the purposes of this explanation. Within the marketing team, we’ll have one key point-of-contact (usually the exec admin for the marketing leader), which is who we assign as the primary administrator. The marketing department will often have different product managers, each with their own team. So, product managers are usually set up as additional admins, while their team members are general users.
We work with a lot of wealth management companies, where each financial advisor operates as their own business unit (BU). They also often have their own teams of support personnel, sometimes each needing different levels of access to data. A lead support person may need all data, while a junior support person needs to have limited access. So, at the BU level, we need to have a primary admin (advisor), additional admins (support leads), and general users (junior support).
This allows marketing to order gifts at the company level or for their own team, while also having insights into what each BU is ordering so they can evaluate the company gifting program’s overall efficacy. (We also have a gift-of-choice platform in our app where each BU can have their own messaging on the shop page. We feed that data to a page accessible on the enterprise-level dashboard so that marketing can ensure each BU’s messaging is on-brand, and edit it if not.) Meanwhile, it allows advisors and their teams to order their own gifts without having to ask marketing to do so. And, the BU-level visibility lets them see what others on their team have already ordered so there’s not duplicate gifts sent. (The dashboard also contains receipts for download so marketing isn’t having to provide those either.) The enterprise-level data is downloadable for marketing, while the BU-specific data is downloadable for a given BU.
How It’s Done:
When a client first starts to work with us, we have a form that captures the core company info and the contact info for the primary admin for the enterprise. It’s the same form we use for other new client intake, but it includes an additional data point in a hidden field, which I’ll explain in a second. This form feeds to the Users table in Airtable, creating an individual magic link for that primary admin user. The form also includes a couple of hidden fields indicating that this is a brand-new client that doesn’t already have a client record with us. Once that form submission hits the Users table in Airtable, automation detects that it’s for a new client, which then causes a record to be created in our Clients table.
A new record in our Clients table then triggers automation that assigns a client code to that record. That client code is crucial to all of our automation and app permissions. It’s a single letter that corresponds to the company name (Apple=A, Microsoft=M, Nordstrom=N, etc.) and a four digit number that’s sequentially created within each letter through some other Airtable tables and automation. So, if Apple is the 15th client to start with A, they’d be A1015. If Nordstrom were the 27th client whose name starts with N, they’d be N1027.
Why this matters here is that, by doing it this way, it allows for up to 233,974 total client codes (8,999 per letter since each letter starts at 1000) to be created without affecting various formula syntaxes throughout the tables that rely on it being a single letter plus ####. In the case of an enterprise, the enterprise is assigned a client code, but so also is each BU. By treating the enterprise as one client code and each BU as its own client code, it allows us to tie the data together in different ways, while also assigning different permission levels at both the enterprise and BU level.
In the Clients table in Airtable is a field named “Is a Master Unit”. It’s a single-select Yes/No field, with No as the default. The data point in the hidden field I mentioned earlier in the client intake form is this field. It has “Yes” in it by default, and we know to send that form to new clients who will be utilizing an enterprise account setup. (If a client is coming onboard and they’re not needing an enterprise-level account, we send them a different version of the same form, where “No” is in the hidden “Is a Master Unit” field.) That way, we don’t have to remember to manually change the field, which would also delay other automations from being triggered immediately. (And then, should a company later need to add individual BUs, we can manually change the field and the automations then happen related to that change.)
In the Users table, where each user is linked to a client, that linked field looks up the “Is a Master Unit” field from the Clients table. (When a new primary admin user is added to the Users table, the “Is a Master Unit” field is copied to an “Is a Master Unit” field in the Clients table, which then allows anyone tied to the client record to share that same setting, rather than just at the individual user level.)
This become important because in our client dashboard, we have an “Add User” button and an “Add New Business Unit” button for those who are enterprise-level accounts. In our example’s case, this would be marketing. So, if a primary or additional admin were to click “Add User”, they could add a user to their team, either as an additional admin or general user, giving them each their own magic link. The “Add a User” form has a hidden field containing the enterprise-level client code. That feeds to the linked Clients record field in the Users table so that the lookup field for that user has “Yes” for “Is a Master Unit” as, like I explained, that is now at the client level and not just the individual level. That way, anyone added as an additional admin or general user for the marketing team is already specified to be part of that enterprise-level team.
Then, if “Yes” appears in the lookup field for that user, their dashboard also includes a button named “Add New Business Unit”. The use of this button adds an entirely new BU that falls under the enterprise. For instance, a new advisor and their team. This is NOT for adding a new user within a respective advisor’s BU account. It’s solely for adding a new BU that has not previously been added. The button opens a modal form, for which we use Fillout Forms specifically because it has some text calculation capabilities that are really helpful here. (You could do the same in Airtable through formulas and automations, but it’s just simpler doing it in the form itself.)
The form feeds to the Users table to create a new user record for a primary admin–for what’s considered to be a new client as far as Airtable is concerned. And in so doing, it creates a magic link for that primary admin. The “Add New Business Unit” form has hidden fields to indicate it’s a new client (just like our regular intake form), but there’s also a hidden field where “No” is in the “Is a Master Unit” field and then a hidden field containing the enterprise account’s client code that feeds to a field in the Users table named “Master Unit #”. So, the end result is a new user being added to the Users table as if they’re a new client, specified to not be a master unit (e.g., part of the enterprise level group), and the enterprise level group’s client code is in a field named “Master Unit #”. That’s the field that ties them to the enterprise.
But, when it comes to the company name for the BU, it can’t be the same exact company name because the client codes automation requires each name to be unique. So, in Fillout, we use the calculation feature to cause the company name going into Airtable for a new BU to be formatted as [Company Name] | [User Full Name]. So, those at the enterprise level would just have “Merrill Lynch” for their company name, but for the BUs, their company names would go in as “Merrill Lynch | John Doe”, “Merrill Lynch | Jane Smith”, etc., where the name would be the advisor’s name. (If you did this as departments instead of individuals, you could add a field to the form to capture the department’s name so then it would be “Merrill Lynch | Sales”, “Merrill Lynch | HR”, etc., or a geo location like “Merrill Lynch | Seattle”, “Merrill Lynch | Phoenix”, etc.)
Then, as a new company name, each BU is assigned its own client code. But, because their client record has “No” for “Is a Master Unit”, their dashboard only contains the “Add a User” button. Their BU client code is in a hidden field tying the user to that BU. But, there’s also a hidden field with the enterprise-level client code that feeds to the “Master Unit #” for each added user within a BU. So, each added user in a BU has their own magic link, is tied to their BU through a linked client code, and they’re specified to be part of the overall enterprise’s client code.
It’s rare that a business unit will have its own logo (though we’ve set it up to allow for that as well in specific situations), so by using the linked record field to tie every BU client code to the enterprise client record and, in turn, each individual under the BU to the enterprise client record, a lookup field in the Users table pulls the logo field from the enterprise client record. We can then reference that field for any time a logo needs to populate on the dashboard or wherever, without having to add the logo file each time.
I know that’s a ton of info, but hopefully it’s of help to someone along the way. We continue to perfect it as new features are added to Softr and Airtable, but right now that’s the best way we’ve gotten it to work not just to get each individual their own magic link, but also hierarchy-enabled access at two different levels. It’s allowed for really comprehensive dashboard capabilities, ease-of-use, and a lot less work on everyone’s part.