<?xml version="1.0" encoding="UTF-8"?><rss xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:atom="http://www.w3.org/2005/Atom" version="2.0"><channel><title><![CDATA[Topics tagged with saas]]></title><description><![CDATA[A list of topics that have been tagged with saas]]></description><link>https://fusionauth.io/community/forum/tags/saas</link><generator>RSS for Node</generator><lastBuildDate>Tue, 15 Sep 2026 18:49:12 GMT</lastBuildDate><atom:link href="https://fusionauth.io/community/forum/tags/saas.rss" rel="self" type="application/rss+xml"/><pubDate>Invalid Date</pubDate><ttl>60</ttl><item><title><![CDATA[Best practice for storing additional metadata for users]]></title><description><![CDATA[<p dir="auto">You can use the user.data and registration.data fields to store arbitrary key value data.</p>
<p dir="auto">If the metadata is associated with the user, use user.data. If it is associated with the user's account for a given application, use registration.data.</p>
<p dir="auto">Note that this field is read/write via the API, but only readable via the administrative UI.</p>
<p dir="auto">Here are some notes about the limits of these fields: <a href="https://fusionauth.io/community/forum/topic/89/how-large-can-the-data-field-be-for-any-of-the-fusionauth-resources">https://fusionauth.io/community/forum/topic/89/how-large-can-the-data-field-be-for-any-of-the-fusionauth-resources</a></p>
<blockquote>
<p dir="auto">And for the latter option, should I use a webhook for registration events</p>
</blockquote>
<p dir="auto">If you want a separate database, that's the way to do it. Listen for a webhook and create the records then.</p>
<p dir="auto">Whether you should use the data fields or a separate database depends on what you are trying to do. The data fields are simpler and more tightly tied to the user records. You can also query them, but you'll be writing elasticsearch queries.</p>
<p dir="auto">If you'd rather write straight SQL or will be storing lots and lots of data about a user (for example, their entire login history for analytics), then a separate database might work better. Of course, that's another system to maintain, so more complexity is the tradeoff.</p>
]]></description><link>https://fusionauth.io/community/forum/topic/343/best-practice-for-storing-additional-metadata-for-users</link><guid isPermaLink="true">https://fusionauth.io/community/forum/topic/343/best-practice-for-storing-additional-metadata-for-users</guid><dc:creator><![CDATA[dan]]></dc:creator><pubDate>Invalid Date</pubDate></item><item><title><![CDATA[Building an admin portal based on FusionAuth]]></title><description><![CDATA[<p dir="auto">If you want to add or remove a registration from a user (registrations are how a user is authorized to use an application) you could either allow someone to use the FusionAuth admin screen (possibly with a limited role) or you could use the API to build your own more limited interface.</p>
<p dir="auto">Here's the API call you would want for this specific use case: <a href="https://fusionauth.io/docs/v1/tech/apis/registrations#delete-a-user-registration" rel="nofollow ugc">https://fusionauth.io/docs/v1/tech/apis/registrations#delete-a-user-registration</a></p>
]]></description><link>https://fusionauth.io/community/forum/topic/340/building-an-admin-portal-based-on-fusionauth</link><guid isPermaLink="true">https://fusionauth.io/community/forum/topic/340/building-an-admin-portal-based-on-fusionauth</guid><dc:creator><![CDATA[dan]]></dc:creator><pubDate>Invalid Date</pubDate></item></channel></rss>