Skip to main content

Application Management

The Console Applications module manages installed GeniApps and registered applications in the active space. Industry-solution deployment begins in Explore, but the applications it creates or installs are governed here.

Access​

Open Console → Applications. Viewing requires application read permission; changing membership, roles, configuration, or lifecycle state requires the corresponding administrative permission.

Application types​

TypeDescription
WorkbenchConfiguration-driven low-code application with drafts and published versions
GeniAppCode-based application installed from the built-in catalog
Embedded agentFocused authorized agent experience
External/SSO applicationRegistered external URL or single-sign-on integration

Install a GeniApp​

  1. Open the application catalog or marketplace available in your edition.
  2. Review the description, requested resources, roles, permissions, and version.
  3. Select the target space.
  4. Start installation.
  5. Follow the background job status until every required stage completes.

Installation may create or update application records, roles, Datasources, database schema, agents, tasks, or other declared resources. A failed job reports the stage and can be retried according to the application contract.

The public marketplace may be hidden in a self-hosted deployment; administrators can provide an approved internal catalog instead.

Industry solutions​

Industry solutions are deployed from Platform Hub → Explore and can initialize a wider resource set than a single GeniApp. Follow the Industry Solutions guide for progress, existing-space confirmation, and upgrade-safe Workbench drafts.

Register a custom application​

  1. Select Create Application.
  2. Choose the supported application type.
  3. Enter the name, description, icon, and launch configuration.
  4. Configure embedded-agent binding, URL, or SSO fields as required.
  5. Save and test with a non-administrator user.

Only use trusted HTTPS origins for external applications.

Configure an embedded agent securely​

An embedded-agent application lets a third-party product provide a bounded Agent experience without giving the browser a long-lived platform credential.

  1. Select the allowed Agent and the features the embedded experience needs.
  2. Register the exact trusted HTTPS origins. Avoid wildcard origins.
  3. Create the application credential and keep it only on the host application's backend.
  4. When an external user opens the experience, have the backend request a short-lived, one-time launch ticket using a stable user_code.
  5. Let the embedded client exchange the ticket for its application-scoped session.
  6. Test Agent access, memory behavior, rate limits, and sign-out with a non-administrator external user.

The long-lived application key must never be placed in iframe HTML, browser storage, frontend environment variables, or public source code. Launch tickets are single use and short lived; session access is limited by application, origin, allowed Agent, features, and the mapped external user.

Embedded memory uses the mapped external-user identity and remains separate from an ordinary GeniSpace user's personal memory. Changing a user's user_code creates a different memory subject.

Members and roles​

The Users area grants application access to valid members of the parent space. The Permissions area maps roles to the permissions declared by the application.

  • System roles supplied by an installed application's rbac.json are read-only in Console.
  • Change a system role by upgrading the application contract, not by editing it locally.
  • Custom roles can be created where supported and should use the smallest practical permission set.
  • Reassign members before deleting a custom role that is still in use.

Application access cannot exceed the user's space membership or the permissions of underlying data and tools.

Status and publishing​

Common lifecycle states include draft, active/published, paused, and archived, depending on application type. Workbench publication is managed in Workbench; pausing the application entry controls launch availability and does not replace Workbench version history.

Upgrade​

Before upgrading:

  1. Review release notes and resource changes.
  2. Save important local drafts and record customizations.
  3. Check data migrations and role changes.
  4. Start the upgrade and monitor its background job.
  5. Test the upgraded application with representative users.

For industry solutions, review and publish the generated Workbench draft separately. Restoring a Workbench version does not roll back an external database migration.

Uninstall​

Uninstall can remove application access and managed resources according to the application contract. Review data-retention and dependency warnings before confirming. Export data that must be retained.