Skip to main content

Organization slug

Your organization has a short, URL-safe identifier called a slug. It's auto-generated from your org name when the org is created — for example, "Alpha Beta Gamma" becomes alpha-beta-gamma — but you can edit it. The slug appears in the public application URL, in audit log payloads, and in a handful of internal references.

This page explains where the slug shows up, what's allowed, how to change it, and what breaks when you do.

What the slug is used for​

Today, in v0.62.1, the slug is part of exactly one user-facing URL:

URLWhat it is
app.greekmanage.com/apply/<slug>Your public PNM application page (the form prospective new members fill out from outside the app)

It is not used for:

  • Public donation URLs. Those are scoped to a Foundation campaign — /donate/<foundation_id>/<campaign_slug> — and use the campaign's own slug, not the org slug. Changing the org slug does not affect donation links.
  • Custom branded URLs / vanity domains. GreekManage does not support per-org custom domains in v0.62.1. The PNM apply URL is always app.greekmanage.com/apply/<slug> — there is no way to swap that to recruit.yourorg.com or similar. (This is on the backlog; if it ships, it'll be a separate feature.)
  • Org sign-in URLs. Sign-in is the same app.greekmanage.com URL for every org; org identity is resolved after authentication, not by URL.
  • API paths. API endpoints use org UUIDs, not slugs.

So in practice: the slug is your public-apply identifier. That's the surface you care about.

Where you change the slug​

Org → Settings → PNM (or "Recruitment") → Public Application Page card.

The card displays the current Apply URL — <your host>/apply/<slug> — with a copy button, and below it the editable Slug field with an Update button.

PNM Public Application Page card with slug field PNM Public Application Page card with slug field

The card is part of the PNM module's settings surface — it lives there because the apply URL is the only thing the slug currently controls. If you don't see the card, the PNM (recruitment) module isn't enabled for your org; turn it on at Org → Settings → Modules (see Module enablement).

Slug rules​

The slug must satisfy all of:

  • Length: 1 to 64 characters.
  • Characters: lowercase letters (a-z), digits (0-9), and internal hyphens (-) only.
  • No leading or trailing hyphens. Hyphens are allowed only between other characters.
  • Unique across all orgs on the platform. Two orgs cannot share a slug.
  • Not a reserved word. A list of reserved slugs is blocked to prevent collisions with existing routes and reserved platform paths:
admin, api, auth, public, apply, org, chapter, region, platform,
static, media, health, docs, www, assets, files, download, uploads,
login, logout, register, signup, signin, signout, me, user, users,
settings, dashboard, home, help, support, about, legal, privacy, terms

If you try to set the slug to any of those, the field rejects the change.

Examples​

SlugValid?Why
phi-rho-deltayeslowercase, internal hyphens
phirho123yesletters and digits
Phi-Rho-Deltanouppercase letters not allowed
-phi-rhonoleading hyphen
phi--rhoyesdouble internal hyphens are allowed (regex permits consecutive hyphens)
applynoreserved word
adminnoreserved word
ayesminimum length is 1
65-character stringnoover the 64 limit

Step-by-step: change the slug​

  1. Open Org → Settings → PNM (or Recruitment).
  2. Find the Public Application Page card.
  3. The current Apply URL appears at the top. Copy and stash it somewhere — you'll want a record of what it was before.
  4. Edit the Slug field. The Update button is disabled until your value differs from the current one.
  5. Click Update. The system validates the new value (rules above) and saves it.
  6. The Apply URL field updates immediately to reflect the new slug.

You'll get a toast: "Apply URL updated. Previously shared links will stop working."

What just broke​

Everything that referenced the old /apply/<old-slug> URL is now dead. The system does not maintain redirects; the old slug is released and another org could even claim it (though the validation prevents recently-claimed slugs from being immediately reused if there's a collision).

Concretely, you should review:

  • Marketing materials — flyers, social posts, the org website, anything that linked the recruitment URL. Update them.
  • Email signatures and templates — recruitment chairs often paste the apply URL into their signature.
  • QR codes — if you printed QR codes pointing at the old URL, they're now dead. Generate new ones from the updated URL.
  • Bookmarks — internal officers may have bookmarked the apply form to monitor or test it. Send a heads-up that the URL has changed.
  • Bulletin templates and onboarding emails — anywhere the URL was embedded.

There is no in-product list of "where this URL appears externally" because GreekManage doesn't track external usage. Treat the slug change as a deliberate redirect-less migration.

When to change vs. keep the slug​

Keep the auto-generated slug if it's fine — it usually is. The slugify rule produces sane results from typical org names.

Change it when the auto-generated slug is awkward or hard to remember, the org has rebranded, you got a numbered suffix from a collision (alpha-beta-gamma-2), or you want a shorter version (abg instead of alpha-beta-gamma).

Don't change it casually mid-recruitment cycle. Active applicants who bookmarked the form lose access; printed materials become wrong overnight. If you must change during recruitment, communicate the new URL explicitly to active prospects.

What officers and members see​

Chapter officers and members don't see the slug-editing card. PNM settings are an org-admin-only surface. Officers can paste the resulting apply URL into outreach but cannot edit it. Regional admins also don't have access to the slug-editing UI in v0.62.1.

Mobile differences​

The card renders on mobile. Most slug changes happen alongside marketing-material updates that are much easier on desktop, so plan accordingly. The Apply URL copy button works on mobile.

Errors and edge cases​

ErrorCauseFix
"Slug must be lowercase letters/digits with optional internal hyphens, 1-64 characters, no leading/trailing hyphen."Pattern violation (uppercase, special chars, leading/trailing hyphen, too long, too short).Adjust to match the rule.
"This slug is reserved."You chose a slug in the reserved list (see above).Pick a different value.
"Slug already in use."Another org has it.Pick a different value. The collision is across the whole platform, not just your org.
Update button stays disabled.Your typed value is identical to the current slug, or you have an outstanding validation error.Modify the field, or fix the validation issue.
Apply URL field shows the new slug, but the form at /apply/<new-slug> 404s.Browser cached the old apply page.Hard-refresh the apply page in a private window to confirm the new URL works.

Troubleshooting​

"Applicants are still using the old URL." Browsers cache the apply form. They need to clear cache or open a new private window. Bookmarked old URLs are dead — send the new one.

"I want a custom domain like recruit.alphabetagamma.org." Not supported in v0.62.1. The apply URL is always app.greekmanage.com/apply/<slug>. Workaround: put a 3xx redirect on your existing org website pointing /apply to the GreekManage URL. There is no custom TLS termination today.

"Our slug got auto-generated with a suffix like phi-rho-delta-2." The collision was with another org. Update to a different unique value (phirhodelta, prd-yourstate, etc.) using the steps above.

"Someone might take our old slug after we change." Once released, another org could in theory claim it. In practice the platform team monitors slug churn and won't reissue without coordination. Ask them to soft-block if you're concerned.

"My existing slug would be reserved today." The reserved list has expanded over time. Existing slugs aren't retroactively invalidated, but you cannot change to a reserved word now. If you have a now-reserved slug, you can keep it — but changing away from it means you can't change back.

Last verified against v0.62.1 (2026-05-11).