Access Settings

Access Settings allow administrators to control the entry points for new users on the Freedam platform. This interface centralizes how accounts are created, whether through direct invitations, open self-registration, or corporate Single Sign-On (SSO) providers.

By managing these settings, you can ensure that only authorized individuals gain access to your digital assets while automating the assignment of initial permissions for new members.

Page Overview

• Purpose: To define the security and onboarding rules for new user accounts.
• When to use it: Use this page during initial setup or when you need to change how users join the platform (e.g., switching from invitation-only to open registration).
• What you can do here:
  • Enable or disable user-to-user invitations.
  • Toggle public self-registration.
  • Require administrative approval (accreditation) for new sign-ups.
  • Restrict registration to specific corporate email domains.
  • Enable Single Sign-On (SSO) with Google, Microsoft, or both.
  • Choose whether a first SSO sign-in creates an account, and with which role.
  • Require single sign-on for everyone except administrators.
  • Set the default role assigned to new users, and a different role for chosen email domains.
  • Require approval for every new rendering.

Page Layout

• Top bar: Displays the page title "Access Settings" and the Save Changes button.
• Main area: A centralized card containing a list of toggle switches and configuration fields for registration and authentication.

Who can use it

Access Settings can only be opened and changed by people with the Manage system settings permission. Other team members will not see the page in the admin navigation.

The role settings on this page (Default Role, Roles by Email Domain and the role for new SSO accounts) also need the Assign roles to users permission to choose a role other than the current default role.

Main Features

Registration Control

• What it's for: Determining if users can create their own accounts or if they must be invited.
• Where to find it: The Invitations and Self-Registration switches at the top of the list. Invitations allows users to be invited by email. Self-Registration allows people to register without an invitation.
• Typical use: Turn off Self-Registration if you want a private, invite-only environment.
• Result: The "Sign Up" option will appear or disappear from the login screen. When self-registration is off, anyone landing on the sign-up page who does not carry a valid invitation link is blocked with a clear message that registration is by invitation only.

Accreditation (Admin Approval)

• What it's for: Adding a manual review step for new users.
• Where to find it: The Accreditation switch, below Self-Registration. It is locked while Self-Registration is off.
• Typical use: Enable this if you allow self-registration but want to verify each person's identity before they see any assets.
• Result: New users are redirected to a request-access form instead of the normal sign-up flow. Their submission lands in the User Requests queue, where administrators - or a dedicated accreditation reviewer group if one has been configured - approve or deny the applicant. Nobody sees any assets until they are approved. People who follow an invitation link are not sent to this form: the invitation already counts as approval, so they go straight to account creation.

Domain Restriction

• What it's for: Limiting access to specific organizations.
• Where to find it: The Email Domain Restriction switch. See Email Domain Allowlist for the steps.
• Typical use: Enter your company domain (e.g., "company.com") to prevent anyone with a personal email (like Gmail or Yahoo) from registering.
• Result: Registration attempts from non-listed domains are blocked before the account is ever created. The same allowlist also applies when an account would be created on a first SSO sign-in, so a personal Gmail or Outlook.com address gets no account even when the matching provider is turned on. People who already have an account can still sign in with SSO.

Single Sign-On (SSO)

Freedam supports two SSO providers, each with its own independent switch:

• Google - for Google Workspace and Gmail accounts.

• Microsoft - for Microsoft Entra ID (formerly Azure AD) work or school accounts, and personal Microsoft accounts.

• What it's for: Allowing users to log in with an account they already have, instead of creating another password.

• Typical use: Streamlining the login process for employees who already live in Google Workspace or Microsoft 365.

• Result: A "Continue with Google" and/or "Continue with Microsoft" button appears on the login page - one per enabled provider. If a provider's credentials have not been configured at the server level, its toggle stays disabled and the page will tell you so; no save is needed.

You can enable either provider on its own, or both at once. Turning one off does not affect the other, and users who already linked that provider simply lose it as a sign-in option - their account and assets are untouched.

Account creation on first sign-in

When a provider is switched on, two more settings appear below its switch:

• Create accounts on first sign-in: when on, a person without an account gets one the first time they sign in with that provider. When off, only people who already have an account can sign in with that provider. It is off by default.
• Role for new Google accounts / Role for new Microsoft accounts: the role of the accounts created this way. The first option, "Default role ({role})", follows the Default Role setting. A role set under Roles by Email Domain takes priority over this one. The dropdown is locked while Create accounts on first sign-in is off. Choosing a role other than the default role needs the Assign roles to users permission.

Both settings are saved with Save Changes, like the rest of the page.

Plan requirement

Single sign-on is included in the Business plan and in Tailored plans. On the Free and Team plans, the Google and Microsoft switches are still shown on this page, but they are locked and carry an upgrade notice. The SSO providers description then reads "{provider} SSO is not included in your current plan. Your saved setting is kept and applies again once your plan includes single sign-on."

A provider you switched on earlier, for example during the 30-day trial (which unlocks every feature), keeps its stored setting. While your plan does not include single sign-on:

• The login and registration pages show no SSO buttons.
• Require single sign-on has no effect, so password login always works.
• Users who only ever signed in through SSO can use the normal password reset to set a password.
• Their linked identity stays listed under user settings, in Connected accounts, with a notice explaining that single sign-on is not included in the workspace's current plan. They can still disconnect it.

After an upgrade, or a per-tenant override granted by the Freedam team, everything resumes exactly as configured, including enforcement. Nothing needs to be set up again. Trying to switch a provider on while the plan lacks SSO fails with "Single sign-on is not available on your current plan. Upgrade to enable a provider." Re-saving the page with a provider that is already on keeps working.

Require single sign-on

• What it's for: Making single sign-on the only way in for regular users, so access follows your company's Google Workspace or Microsoft account lifecycle.
• Where to find it: Just below the Google SSO and Microsoft SSO rows, look for Require single sign-on.
• Typical use: Once every employee signs in with SSO, turn this on so that disabling someone's corporate account also locks them out of Freedam.
• Result: The login page shows only the SSO buttons. Anyone who is not an administrator and tries to sign in with a password is refused with a message that the workspace requires single sign-on.

The switch can only be turned on while at least one SSO provider is switched on (and, for plan-gated workspaces, while the plan includes single sign-on). Until then it stays greyed out and its description asks you to switch on a provider first. If it was turned on earlier and the providers were later switched off, it has no effect and you can still turn it off.

Administrators always keep a way in with their password, so a misconfigured provider can never lock the workspace out. On the login page, an Administrator sign-in link below the SSO buttons opens the usual email and password form. The link is visible to everyone, but only accounts with the Administrator role can sign in through it.

The same rule applies to Sign in to your workspace on the Freedam website: a password sign-in there is refused with the single sign-on message unless the account has the Administrator role, so the website is not a way around enforcement.

Require Rendering Approval

• What it's for: Reviewing every new rendering before other people can see or download it.
• Where to find it: At the bottom of the settings list, look for Require Rendering Approval.
• Typical use: Turn it on when crops, social media exports and template results must be checked for brand compliance before they circulate.
• Result: New renderings (uploads, crops, social media exports and saved template generation results) show Pending and go to Administration → Asset Requests for review. Until a reviewer approves them, only their creator, the asset's owner and reviewers can see them, and nobody can download them. See Asset Requests.

AI edits always require approval, whether this switch is on or off. Turning the switch on or off does not change renderings that already exist: only renderings created afterwards follow the new setting. Template generation results are submitted when they are saved, never while they are unsaved drafts.

Detailed Feature Documentation

Default Role Assignment

• Purpose: Gives every new account a role, and therefore a set of permissions, when nobody chooses one for it.
• Where to find it: The Default Role row, below the single sign-on settings.
• What you'll see: A dropdown menu listing every role of the workspace, system roles and custom roles alike.

The default role is given to people who register themselves, to people whose account is created on their first SSO sign-in (see Account creation on first sign-in), and to people who accept an invitation that sets no role. It is also the role pre-selected when an administrator approves an account request. An invitation that names a role gives that role instead.

How to use it:

1. Locate the Default Role row.
2. Click the dropdown menu (currently showing the active role).
3. Select the desired role from the list.
4. Click Save Changes in the top bar.

Good to know:

• Choosing another default role needs the Assign roles to users permission in addition to Manage system settings. Without it the dropdown is locked, and its description reads "Changing it requires permission to assign roles."
• Changing the default role does not change the role of existing accounts.
• While a role is the default role, it cannot be deleted and its code cannot be changed on the Role Management page.
• Anyone who may invite users or approve account requests can give the default role. Giving any other role needs Assign roles to users.

Roles by Email Domain

• Purpose: Gives new accounts from chosen email domains a role other than the default role. A typical use is to keep the standard User role for your own company's domain and give everyone else a restricted default role.
• Where to find it: The Roles by Email Domain row, below Default Role.
• What you'll see: A field for the domain, a role dropdown, an Add button, and the list of domains already set.

A role by email domain applies when a person registers, gets an account on their first SSO sign-in, or accepts an invitation that sets no role. Roles are looked up in this order:

1. The role chosen on the invitation, if there is one.
2. The role set for the person's email domain under Roles by Email Domain.
3. For a first sign-in with SSO, the Role for new Google accounts or Role for new Microsoft accounts, if one is set.
4. The Default Role.

How to use it:

1. Type the domain in the field, for example nordi.example, without the @.
2. Choose the role in the dropdown next to it.
3. Click Add. The domain appears in the list, where you can change its role or remove it.
4. Click Save Changes in the top bar.

Good to know:

• Each domain can have only one role.
• Choosing a role other than the default role needs the Assign roles to users permission. Without it, a note explains that a domain can only be given the default role, and roles already set can be kept or removed.
• A role by email domain does not change the role of existing accounts.
• A role used here cannot be deleted, and its code cannot be changed, until you remove it from this list.
• This setting does not restrict who can register. To limit registration to some domains, use the Email Domain Allowlist.
• If the role allows administration permissions and your plan has no free administrator seat, the new account is not created. See Role Management.

For a complete example, see Set up a restricted role for external partners.

Email Domain Allowlist

• Purpose: To restrict self-registration to specific verified domains.
• Where to find it: Look for the Email Domain Restriction switch.
• What you'll see: When switched on, an Allowed Domains area appears with a field to add a domain, an Add button, a Paste list button, a search field, and the list of domains with their count.

How to use it:

1. Switch Email Domain Restriction on.
2. Under Allowed Domains, type a domain (e.g., acme.com) in the field.
3. Press Enter or click Add. The domain appears in the list.
4. Repeat for additional domains if necessary. To remove a domain, click the remove button on its entry.
5. Click Save Changes.

To add many domains at once, click Paste list. In the Add multiple domains dialog, paste domains or email addresses separated by commas, spaces or line breaks. Anything before an @ is ignored. The dialog shows how many domains are new, how many are already listed, and which entries are skipped as invalid. Click Add N domains to add the new ones, then Save Changes.

When the list is long, use Search domains… above it to find an entry.

Complete Workflows

Workflow: Setting up a Private Corporate Portal

• Goal: Ensure only employees with a company email can join, but require admin approval for extra security.
• Prerequisites: Administrator access.

Steps:

1. Navigate to Access Settings.
2. Switch Self-Registration to ON.
3. Switch Accreditation to ON.
4. Switch Email Domain Restriction to ON.
5. Under Allowed Domains, type your company domain and press Enter.
6. Select your base role (for example User) in Default Role.
7. Click Save Changes.

• Expected result: Only users with your company email can sign up; they will remain "Pending" until you approve them, and they will start with the permissions of the default role.

Workflow: Enabling SSO Login

• Goal: Allow users to bypass password creation by signing in with Google or Microsoft.
• Prerequisites: The chosen provider's OAuth credentials must be configured in the system environment, and your workspace plan must include single sign-on (Business, a Tailored plan, or the 30-day trial).

Steps:

1. Locate the Google SSO or Microsoft SSO row - there is one per provider.
2. If the description invites you to allow users to sign in with that account, flip the switch to ON.
3. If the description mentions that the provider "is not configured," contact your system technical lead.
4. If the switch is locked with an upgrade notice, your plan does not include single sign-on. Upgrade from Admin → Plan & Usage, then come back to this page.
5. To let people without an account sign in, switch Create accounts on first sign-in on and choose the role for the new accounts. Leave it off if only existing users should sign in with this provider.
6. Repeat for the second provider if you want to offer both.
7. Click Save Changes.

• Expected result: The login screen will now display one authentication button per enabled provider.

If your plan later drops single sign-on, the switches lock again but keep their saved position. The SSO buttons disappear from the login and registration pages and password login always works in the meantime. Once the plan includes single sign-on again, or the Freedam team grants your workspace an override, the providers you had enabled come back on their own, with any Require single sign-on enforcement applied as before.

Workflow: Requiring single sign-on

• Goal: Make Google or Microsoft sign-in mandatory for everyone except administrators.
• Prerequisites: At least one SSO provider is set up and working (see the previous workflow). Check that you can sign in with it yourself before enforcing it.

Steps:

1. Make sure Google SSO, Microsoft SSO, or both are switched ON.
2. Switch Require single sign-on to ON.
3. Click Save Changes.

• Expected result: The login page only offers the SSO buttons, plus a small Administrator sign-in link. Users who try a password are told the workspace requires single sign-on.
• If it doesn't work: If the switch is greyed out, no provider is switched on yet, or your plan does not include single sign-on.

Limits and guardrails

• Each allowed domain must be a valid, lowercase domain name (for example acme.com or team.acme.co.uk). Entries that are not real domain names are rejected with a friendly message when you try to save.
• When the domain restriction is turned on, you must provide at least one domain before you can save the page.
• Leading @ signs and mixed capitalisation are cleaned up automatically - @Company.COM becomes company.com - and duplicate entries are removed silently.
• Invitations always bypass the allowlist. This is intentional: it lets you onboard an outside contractor without having to add their personal domain for everyone.
• Invitations also bypass the registration mode. A valid invitation link opens the account creation form even when self-registration is off or accreditation is on.
• A role named by Default Role, Roles by Email Domain or the role for new SSO accounts cannot be deleted, and its code cannot be changed, while it is used here.
• A person who registers and would get a role with administration permissions is refused when your plan has no free administrator seat.
• Require single sign-on never applies to administrators. They can always sign in with their password through Administrator sign-in on the login page.

What happens behind the scenes

• Every change made on this page is recorded in a setting change log with the administrator's name, the old value, the new value, their IP address, and the time of the change. The full history is available for compliance and auditing.
• Saving the page also refreshes the onboarding checklist so that newly completed steps (for example configuring an SSO provider) show as done for every administrator.
• When accreditation is enabled, a dedicated reviewer group - if one has been assigned under User Groups - receives the pending requests instead of the general administrator pool.
• New users who self-register (without an invitation) are still asked to verify their email address before they can sign in. Users who arrive through an invitation link are considered verified and skip this step.

Tips and Best Practices

• Accreditation Dependency: If you turn off Self-Registration, the Accreditation setting will automatically be disabled, as invited users are typically considered pre-approved.
• Domain Formatting: You don't need to include the "@" symbol when entering allowed domains. The system will automatically clean entries like @company.com to company.com.
• Invitation Safety: Note that Email Domain Restriction only applies to self-registration and to accounts created on a first SSO sign-in. If an admin or user sends a direct invitation, the recipient can join regardless of their email domain.

Troubleshooting

Issue: Cannot enable an SSO provider

• Symptoms: The switch for Google SSO or Microsoft SSO is greyed out and cannot be toggled.
• Cause: That provider's technical connection (OAuth Client ID and Secret) has not been set up in the server configuration. The two providers are configured independently, so one can be available while the other is not.
• Fix: Contact your IT department or system administrator to configure the environment variables for the provider you want to offer.

Issue: SSO switches are locked with an upgrade notice

• Symptoms: The Google SSO and Microsoft SSO switches are shown but locked, and the description says the provider is not included in your current plan.
• Cause: Your workspace plan does not include single sign-on. It is part of the Business plan and Tailored plans, and of the 30-day trial.
• Fix: Upgrade from Admin → Plan & Usage, or ask the Freedam team for a per-tenant override. Your saved settings are kept: any provider you switched on before, and any Require single sign-on enforcement, applies again as soon as the plan includes single sign-on.

Issue: Cannot turn on Require single sign-on

• Symptoms: The Require single sign-on switch is greyed out and its description asks you to switch on an SSO provider.
• Cause: Enforcement needs a provider people can actually sign in with. No provider is switched on in the form, the provider is not configured, or your plan does not include single sign-on.
• Fix: Switch on Google SSO or Microsoft SSO first; the enforcement switch unlocks immediately, before you save.

Issue: An administrator cannot find the password form

• Symptoms: The login page shows only SSO buttons and the administrator's SSO account is unavailable.
• Cause: Require single sign-on is on, which hides the password form behind a link.
• Fix: Click Administrator sign-in below the SSO buttons to open the email and password form. Only accounts with the Administrator role can sign in there; everyone else is asked to use single sign-on.

Issue: Microsoft users are asked for administrator approval

• Symptoms: A user signing in with a Microsoft work account sees a Microsoft consent screen saying approval from an administrator is required, and never reaches Freedam.
• Cause: This is a Microsoft policy, not a Freedam setting. Microsoft blocks end users from consenting to a multi-tenant application until its publisher has been verified.
• Fix: Your system technical lead needs to attach a verified publisher to the Freedam app registration in Microsoft Entra. Until then, an administrator of the user's own Microsoft tenant can grant consent on their behalf.

Issue: Save Changes fails with an error

• Symptoms: A red error message appears after clicking Save Changes.
• Cause: You likely enabled Email Domain Restriction but did not provide any domains in the list. The message then reads "Please add at least one allowed email domain before enabling domain restriction."
• Fix: Add at least one valid domain under Allowed Domains before saving.
• Prevention: Check that the domain appears in the list below the field before clicking Save Changes.