> ## Documentation Index
> Fetch the complete documentation index at: https://docs.gumloop.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Organization login page
> Customize your organization’s sign-in URL, branding, and allowed sign-in methods, then verify access before rolling it out.
Your organization’s **Login Page** is a branded sign-in screen at `gumloop.com/signin/{your-slug}`. Organization admins choose its URL, name, logo, color, and allowed sign-in methods from [Login Page settings](https://www.gumloop.com/settings/organization/login-page). You can use direct Google or Microsoft sign-in, or add SAML or Okta OpenID Connect.
You need an **Enterprise** subscription and the **Admin** organization role to change these settings. You do not need to configure SSO before setting up the page.
## How do I set up my organization’s login page?
Open **Settings**, then **People & Access → Login Page**. Choose a stable URL and your branding, select the sign-in methods your members can use, then save and test the page before sharing it.
Under **Sign-in URL**, set the **URL** suffix. It must be available and use **2 to 64** lowercase letters, numbers, or hyphens. Gumloop checks availability as you type.
Give members the resulting `gumloop.com/signin/{your-slug}` address. The shorter `gumloop.com/{your-slug}` address redirects to the same page.
Changing the suffix later breaks bookmarks and identity-provider tiles pointing to the old address. Choose a stable name and update those links if you rename it.
Under **Branding**, set the **Organization name**, add a **Logo**, and choose a **Brand color**. The name is required and can contain up to **256 characters**.
Upload a **PNG, JPG, or WEBP** logo up to **2 MB**. Drag and zoom it to fit the frame. Use **Replace** to upload and position a new logo, or **Remove** to clear it.
The **Preview** shows your edits before you save. The brand color tints the glow around the sign-in card; preview both the light and dark appearances.
Select **Google** and **Microsoft** independently under **Direct sign-in**. Under **Single sign-on**, choose **No single sign-on**, **SAML SSO**, or **Okta OpenID Connect**. Only one SSO method can be active at a time.
Set up and test SSO under **Identity Provider** first. SAML needs a live connection; Okta OpenID Connect needs a saved Okta app with a passed test sign-in.
Click **Save changes**. **Discard** returns the form to its saved settings.
If you are switching to SSO-only sign-in, Gumloop asks whether everyone has been assigned to the identity-provider app. Confirm those assignments before choosing **Everyone is assigned, save**. Members at your routed SSO domains who are not assigned to the identity-provider app will be locked out.
After saving, check **Live status** and use **Test sign-in page**. Test the method your members will use before distributing the URL or changing identity-provider tiles.
Saved sign-in restrictions can take up to **five minutes** to appear in Live status. The saved page and the unsaved preview are different: verify the actual saved page, not only the preview.
## Which sign-in methods can I allow?
Direct sign-in and SSO are separate choices. You can allow Google, Microsoft, or both alongside one SSO method, or allow only SSO after confirming member access.
| Setting | What it does | Prerequisite |
| - | - | - |
| **Google** | Direct sign-in with Google Workspace or Gmail | Select the checkbox |
| **Microsoft** | Direct Microsoft sign-in | Select the checkbox |
| **No single sign-on** | Uses the allowed direct sign-in methods | Keep at least one available sign-in method |
| **SAML SSO** | Sign-in through a SAML identity provider, such as Okta, Microsoft Entra, or Google Workspace | A live SAML connection under Identity Provider |
| **Okta OpenID Connect** | Sign-in through your Okta OIDC app | A saved Okta app with a passed test sign-in |
For Microsoft Entra through SAML, choose **SAML SSO**, not the direct **Microsoft** checkbox. When SSO is active, the public page displays **Sign in with SSO** and routes members through the active protocol. See [SSO: SAML, OIDC & SCIM](/enterprise-features/sso_saml_oidc_scim) for identity-provider setup.
Email and password sign-in is not a self-service option here. If Gumloop previously enabled it for your organization, it stays enabled.
## Does hiding a sign-in button enforce a restriction?
Sign-in restrictions are enforced for email domains routed to your organization under **Identity Provider**. Without a routed domain, the page shows the buttons you chose, but members can still use other sign-in methods. Branding the page alone does not enforce SSO.
Before removing direct sign-in, make sure your domain is routed, SSO works, and every affected member is assigned to the Gumloop app in your identity provider. Keep a sign-in method your own admin account can use.
## How do Live status and Test sign-in page work?
**Live status** shows what the sign-in service enforces now, rather than the form’s unsaved choices. For routed domains, it lists the domain and effective sign-in methods. Use **Refresh live status** after saving; changes can take up to five minutes to show.
**Test sign-in page** opens the real page in test mode. Google, Microsoft, and SSO can be checked without changing your current Gumloop session. Email sign-in cannot be tested here; use an incognito window. A successful test verifies your account, not every member's assignment.
## What should I check if setup fails?
The required SSO setup is not ready. Complete the connection under **Identity Provider** first. SAML needs a live connection, and Okta OpenID Connect needs a saved app with a passed test sign-in.
Check the URL, organization name, and allowed methods. The URL must be available and use 2 to 64 lowercase letters, numbers, or hyphens; `sso-complete` is reserved. The name cannot be empty or exceed 256 characters. At least one sign-in method must remain available.
If your admin account’s email domain is SSO-routed, Gumloop also checks that the change leaves you a usable sign-in path. Keep a method you use or complete and test SSO first. If this check cannot complete, Gumloop does not accept the change; keep the existing settings and try saving again once it can.
Saved restrictions can take up to five minutes to show. Refresh Live status and check that the domain is routed under **Identity Provider**. If no domain is routed, choosing buttons for the page does not restrict the methods members can use.
Your successful sign-in verifies your own account, not every member’s assignment. Check that the member’s email domain is routed and that their identity-provider account is assigned to the Gumloop app. Do not switch to SSO-only access until the intended members can sign in.
No. Update bookmarks, company-portal links, and identity-provider tiles when you change the suffix. The old organization address is not kept as an alias to the new one.
## Related documentation
Set up the identity provider and member provisioning.
Understand who can manage organization settings.