Skip to main content

AI Services — tenant re-indexing

The AI assistant searches your organization's data through an embedding index — a numerical representation of every member, forum post, compliance record, and document the assistant is allowed to see. The index is updated automatically in the background, but there are several situations where you need to rebuild it from scratch. This page covers what re-indexing does, when to run it, how to watch it run, and the gotcha around switching embedding providers.

For the relationship between providers and embeddings, see AI Services — provider configuration. For what each content type is, see AI Services — content scope.

Where re-indexing lives​

The Embedding Index card at the bottom of Org → Settings → AI Assistant controls per-organization re-indexing.

You'll see:

  • A Re-index button at the top-right of the card.
  • A table of recent indexing jobs, one row per content type (Member, Forum Post, Compliance, Document), showing the most recent job's status and progress.

the Embedding Index card with a recent run the Embedding Index card with a recent run

A note up top: if your current provider is Anthropic, the Embedding Index card is hidden. Anthropic does not offer an embeddings API, so there's nothing to build or re-build. The chatbot still works — it just uses keyword and fuzzy search rather than semantic search.

What re-indexing actually does​

Clicking Re-index queues a background task per content type. For each one, GreekManage will:

  1. Pull every relevant record from your organization (every active member, every forum post, every compliance submission, every document).
  2. Send the textual content of each record to your AI provider's embedding endpoint.
  3. Receive an embedding vector — a list of floating-point numbers that represents the meaning of the text.
  4. Store that vector in the index, replacing any older version.
  5. Track progress as it goes: total items, processed items, failed items, with full error logs for any failures.

For a moderately sized organization (a few thousand members, low-thousands of forum posts, hundreds of documents) this typically takes a few minutes to an hour. The chatbot remains available throughout — it'll just be searching the partially rebuilt index until the job finishes.

When to re-index​

There are five common situations:

After adding many records​

If you've just done a bulk member import, migrated in a large document library, or imported a chapter's compliance history, the new records won't appear in chatbot answers until they're indexed. The system does have an automatic nightly refresh, but a manual re-index makes the new data searchable immediately.

After switching AI providers​

This is the big one. Different providers produce embeddings of different dimensions:

  • OpenAI (text-embedding-3-small) → 1536-dimensional vectors.
  • Google (text-embedding-004) → 768-dimensional vectors.
  • Anthropic → no embeddings (the assistant falls back to keyword/fuzzy search).

If you've been on OpenAI and switch to Google, every existing embedding in your index is the wrong shape. The chatbot cannot meaningfully compare a 768-dim query embedding against your stored 1536-dim record embeddings — the math doesn't agree. The assistant becomes effectively blind to your data until you re-index against the new provider.

GreekManage detects this case for you. When you switch providers and save, an amber banner appears at the top of the AI settings page:

Embeddings were generated with a different provider. Re-indexing is recommended for optimal AI performance.

The banner has a one-click Re-index Now button. Click it. Until the re-index finishes, expect the chatbot to give vague or empty answers to data lookup questions.

After switching to Anthropic from OpenAI or Google​

Same banner appears. You don't have to re-index in this direction — there's nothing to re-index into, since Anthropic doesn't generate embeddings. The chatbot will fall back to keyword search using the raw text of your records and the stale embeddings will be ignored. But the banner is still shown to make the trade-off visible.

After turning a content-scope toggle back on​

If you previously turned off, for example, the Documents toggle and have now turned it back on, the existing document embeddings (if any) will still be there from the last time the toggle was on — but any documents added during the off period were skipped. Re-index to backfill them.

See AI Services — content scope.

When chatbot answers feel stale​

If your members are reporting that the chatbot doesn't know about recent changes, and you're confident the changes have been saved in GreekManage, a re-index almost always fixes it. The nightly refresh runs at 4 AM but a manual run is fine too.

The jobs table​

The table on the Embedding Index card shows the most recent job per content type:

  • Content Type — Member, Forum Post, Compliance, or Document.
  • Status — Pending (queued), Running (in flight), Completed (finished cleanly), Failed (errors detected).
  • Items — processed / total, with a failed count if any records errored.
  • Completed — when the job finished, or "-" if still running.

If a job failed (red destructive badge, non-zero failed count), the row becomes clickable. Clicking it expands an inline panel with the full error log — one line per failure, usually pointing at a specific record id and a provider-side error like "rate limit exceeded" or "text too long." Use this to diagnose what's going wrong: occasional rate-limit errors during a big run are routine and the platform retries them, but a wall of authentication errors means your API key has been revoked.

The Re-index banner​

Worth saying separately: the amber "Embeddings were generated with a different provider" banner only appears when the provider that last generated your embeddings is different from your currently configured provider. It's a precise indicator that your index is out of shape, not just out of date.

If the banner isn't there, your embeddings match your current provider. They may still be old (data may have changed since the last refresh), but the math will still work and the chatbot will give coherent answers.

Platform-wide re-index​

Platform admins have one more control beyond what individual orgs can do: a Re-index All Tenants button on the platform AI configuration page. Clicking it queues a full re-index for every organization on the platform that is using the platform default provider.

This is the right action after a platform admin changes the platform default — for example, switching the default from OpenAI to Google would invalidate every "use platform default" org's index simultaneously. The platform admin runs one re-index from one button and every affected tenant catches up.

If your org has Custom Configuration, the platform-wide re-index does not include you — you control your own re-index from your own AI settings page.

What about the auto-refresh?​

In addition to manual re-index, GreekManage runs a nightly Celery task at 4 AM platform time that regenerates embeddings for every active tenant. The task respects your scope toggles and your current provider.

In practice, this means:

  • New records made today will be searchable tomorrow morning without you doing anything.
  • A provider switch made today will be auto-healed tomorrow morning, even if you forget to click Re-index manually.

The manual button is for impatience, debugging, or after a big import where you don't want to wait until 4 AM.

Practical re-index flow after a provider switch​

Putting it together:

  1. Change provider from OpenAI to Google (or whatever switch you're making) on the AI Assistant Configuration card.
  2. Paste the new API key.
  3. Click Test, get the green Verified badge.
  4. Save.
  5. The amber re-index banner appears.
  6. Click Re-index Now.
  7. Scroll down to the Embedding Index card and watch the jobs run. Member usually finishes first, documents and forum posts later if you have a lot of them.
  8. When every row shows Completed with zero failed items, your chatbot is back at full strength on the new provider.

If any row finishes with non-zero failed items, click into it, read the errors, and decide whether to re-run. A small number of failures on very long records is normal (some text exceeds the provider's per-call token limit) — those records will fall back to keyword search and the rest of your data will still benefit from semantic search.

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