Define Your Own User Schema

Define Your Own User Schema

What information do you want to collect from your users? Maybe you want to find out how they first found out about you. Maybe you want them to agree to your terms of service. Or maybe you just want to know their name so all your marketing emails don’t start with “Hey… friend,”

For all the fields you want to collect, you can now do so with custom user properties. All you have to do is define the attributes that make up your user object, and PropelAuth handles it from there.

For each field, you can specify things like:

  • Collect it on signup. If so, we’ll automatically update your signup UI with the new field.
  • Collect it on the account page. This is useful for things like your users’ email preferences that you may not want to collect on signup.
  • Require that it’s set before they use the product. This is useful for things like accepting Terms of Service. We can enforce that even if you manually onboarded a user to your product, they must explicitly accept the TOS.

You can check out the docs for the other options. Let’s look at some examples of what you can do:

How did you find out about us (a.k.a. Enums)?

Trying to figure out where a user came from can be challenging, but luckily there’s a simple approach that can work well: Just ask them.

Using our Enum property, you can add a simple field to your signup flow and get a better understanding of which marketing channels are working.

Accepting Terms of Service / Privacy Policy

Want to make sure your users agree to your policies before they sign up? When you toggle on ToS support, you can provide links to your own policies, and we ask them to accept before they can continue.

Importantly, this isn’t just a toggle on the signup page. If your users are manually onboarded via our dashboard or login through a magic link, we will still make sure they agree before they can start using your product.

Metadata (a.k.a. “Just let me do whatever I want with JSON”)

All the properties we’ve talked about so far have been visible to the user. You also may want fields that your users cannot see or modify, like their Stripe Customer ID.

{ "stripe_customer_id": "f46d1803-282b-489a-a151-32e79f50f802" }

With a non-user-facing JSON field, you can store whatever information you want. You can also control whether or not these fields are placed within the JWT, enabling access to the fields without making an external request to us.

Title (e.g. Director, VP) without asking the user

Title is a field that you could ask the user for - however, you can also set it up to be automatically collected for some users.

PropelAuth supports SAML to enable you to quickly onboard enterprise customers. The employees at those companies will login via their work credentials (e.g. with Okta or Azure AD). These SAML connections don’t just log the user in, they also provide some basic metadata about the user. However, it’s up to the company to choose what information they send.

Any fields you specify to collect via SAML will be available during the attribute mapping stage of the SAML setup flow.

And more!

There’s so much more you can do with user properties. If you have any questions, feel free to reach out at support@propelauth.com. We are excited to see what you build!