---
title: "In-App Help Pages"
slug: help-pages
section: Reference
status: stable
description: "End-user help content for Globus staff and applicants — contextual guides accessible from within the application"
last-updated: 2026-10-07
---

# In-App Help Pages

End-user help content for Globus staff and applicants — contextual guides accessible from within the application

> **Help Page Architecture**
>
> Each help page below corresponds to an in-app contextual help panel. Staff and applicants access these via the ? icon within each Globus module. Help content is maintained alongside architecture documentation to ensure consistency between system design and user-facing guidance.

## Role Groups

Role Groups are collections of individual roles that simplify user management. Instead of assigning five separate roles to every program coordinator, administrators assign a single Role Group that bundles the correct permissions for that job function.

### Group Hierarchy

Role Groups are a flat set of named groups with no levels and no inheritance between groups. Each group bundles any number of roles, and every member receives the union of those roles' permissions. A group has a scope that clamps the access it grants:

| Scope | Applies to |
| --- | --- |
| global | All brands and programs (default) |
| brand | A single brand |
| program | A single program |

### Assigning Role Groups

Administrators assign Role Groups from the User Management panel. Each user can belong to any number of Role Groups, in addition to one directly assigned role. When a user has multiple groups, permissions are merged with the most permissive access winning (union model). Program-scoped groups restrict access to specific programs and brands — a user assigned “Camp Coordinator” for SWT-Camp sees only SWT-Camp data.

## Roles & Permissions

The Roles & Permissions system defines what each user can see and do within Globus. Every action in the system is gated by a permission check. Permissions are grouped into roles, and roles are assigned to users directly or through Role Groups.

### Permission Matrix

The permission matrix maps actions to roles:

| Permission | Super Admin | Compliance Mgr | Coordinator | Partner Staff |
| --- | --- | --- | --- | --- |
| View all applicants | ✅ | ✅ | Program-scoped | Partner-scoped |
| Edit applicant data | ✅ | ✅ | ✅ | Limited fields |
| Approve documents | ✅ | ✅ | Assigned types | ❌ |
| Manage users | ✅ | ❌ | ❌ | ❌ |
| Configure workflows | ✅ | ❌ | ❌ | ❌ |
| Override rules | ✅ | With justification | ❌ | ❌ |

### Custom Permission Profiles

Administrators can create custom permission profiles for specialized roles. A custom profile starts with a base role template and allows toggling individual permissions on or off. Custom profiles are audited — every change records who modified the profile, when, and what was changed. Custom profiles cannot exceed the permissions of the creating administrator’s own role.

## Workflow Studio

Workflow Studio is the visual editor for designing applicant workflows. Program administrators use it to define the steps, documents, and compliance gates that applicants progress through. This help page covers the end-user experience of using the Workflow Studio.

### Creating a Workflow

### Publishing & Versioning

Workflows follow a Draft → Published lifecycle. Only one version can be published at a time. Publishing creates an immutable snapshot that the runtime engine consumes. Key rules:

- Existing applicants continue on their current published version until manually migrated
- New applicants automatically receive the latest published version
- Every published version is retained for audit — the 360 Audit Trail shows all historical versions
- Rollback restores a previous version as the active published version
- Version comparison uses side-by-side diffing to highlight step additions, removals, and modifications
### Step Types Reference

| Type | Icon | Purpose | Can Have Children |
| --- | --- | --- | --- |
| Standard | 📄 | A single form or document step. The most common type. | No |
| Hub | 📁 | Groups related steps under a collapsible container. Displays a completion ring. | Yes |
| Subtask | 📎 | A child step within a Hub. Cannot exist at root level. | No |
| Placeholder | ⏳ | Reserved slot for a future step. Shows a "Coming Soon" badge in the portal. | No |

## API Keys

API Keys provide programmatic access to Globus APIs for external integrations, partner portals, and automated workflows. Each key is scoped to specific permissions and can be rotated independently.

### Creating API Keys

### Key Scopes & Permissions

Each API key carries a scope array that limits what it can access. The array mixes permission scopes and resource scopes:

| Scope kind | Examples | Meaning |
| --- | --- | --- |
| Permission scope | `admin.read`, `applications.write` | Grants the permissions mapped to that scope |
| Resource token | `global:`, `brand:`, `program:` and `season:` prefixed tokens | Restricts the key to that resource |
| Wildcard | `*` | Unrestricted access; creating it requires `confirmWildcardScope: true` and a reason of at least 15 characters |

### Key Rotation

Key rotation revokes the old key and issues a new one in a single transaction:

- No grace period: the old key stops working as soon as the new key is issued.
- Every rotation immediately invalidates the old key, and the new key is shown only once in the response.
- Audit log: Every rotation is recorded with the rotating user, timestamp, and reason.
- Notification: The key owner receives an email and in-app alert when rotation occurs.
## Documentation Hub

The Globus Documentation Hub is a centralized entry point linking all help pages, architecture documentation, API references, and onboarding guides. It serves as the single landing page for anyone seeking information about the Globus ecosystem.

In the Hub database, in-app guide content is stored in `guide_sections` (name, unique slug, optional `parent_id`, description, icon, sort order) and `guide_pages` (belongs to a section; title, unique slug, short description, content and the structured fields purpose, who uses this, when to use, key concepts, step by step, edge cases, what happens next, audit notes and common mistakes, plus `related_guides` slugs, sort order, `is_draft` and `last_updated_by`). The "Was this helpful?" thumbs are stored in `guide_page_feedback` (page, optional user, `helpful` boolean, deleted with the page) so documentation audits can report real reader signal per page. Release notes live in `changelog_entries` (title, description, category, optional version, date, details and a list of related endpoints).

### Hub Structure

### Searching Documentation

The Documentation Hub provides a unified search across all documentation sources. Search indexes are rebuilt nightly and include: page titles, section headings, body text, API endpoint paths, and glossary terms. Results are ranked by relevance and grouped by documentation category. Search is accessible via the Hub landing page or the global ⌘K shortcut from anywhere in the application.

## Monthly Check-In

Monthly Check-Ins are a regulatory requirement for on-program participants. Each active participant must complete a check-in form every calendar month during their program period. The check-in captures current status, wellbeing, employment confirmation, and any issues requiring sponsor attention.

> **Regulatory Requirement**
>
> Monthly check-ins are mandated by the Department of State for J-1 Exchange Visitor programs. Sponsors must demonstrate regular contact with participants and maintain records of all check-in responses for compliance audits.

### Staff Guide

Staff manage check-ins through the On-Program Dashboard:

### Applicant Guide

Participants complete monthly check-ins through the Applicant Portal:

### Compliance Tracking

The check-in compliance engine tracks submission status across all active participants:

| Status | Definition | Trigger | Action |
| --- | --- | --- | --- |
| ✅ Completed | Check-in submitted within the calendar month | Form submission | None required |
| 🟡 Pending | Month has started but check-in window is still open | 1st of month | Reminder notification sent |
| 🟠 Overdue | Check-in window has passed without submission | End of month + grace period | Escalation to coordinator |
| 🔴 Non-Compliant | Multiple consecutive months missed | 2+ consecutive misses | Compliance review triggered |
| ⬜ Exempt | Participant marked exempt by staff | Staff action | Documented reason required |