Workspace Administration

Marketplace & tenant apps

Enable tenant apps and launchpad modules from the marketplace.

Marketplace & tenant apps

Marketplace & tenant apps covers module enablement, launchpad app keys, marketplace subscriptions, and tenant-level app availability. Use this page when you are setting up the product surface, reviewing a rollout, or troubleshooting why users see a different result from an administrator.

What this surface is

  • Primary purpose: module enablement, launchpad app keys, marketplace subscriptions, and tenant-level app availability.
  • Where users start: Global settings opens at /global-settings; launchpad Manage apps appears on /launchpad for users with settings permission.
  • Where administrators configure it: Tenant apps include tasks, finance, hcm, attendance, payroll, inventory, shopbyantly, tickets, documents, omnichannel, projects, objects, ats, learning, assets, procurement, and sales.
  • Runtime/detail surface: Enabled apps affect menus, launchpad, permissions, reports, module settings, usage, and available workflow namespaces.
  • Platform connections: Tenant apps connect marketplace subscriptions, launchpad layout, module data, namespace permissions, usage logs, and onboarding.

Where it lives

AreaPath or surfaceUse it for
User surfaceGlobal settings opens at /global-settings; launchpad Manage apps appears on /launchpad for users with settings permission.Day-to-day work and review.
ConfigurationTenant apps include tasks, finance, hcm, attendance, payroll, inventory, shopbyantly, tickets, documents, omnichannel, projects, objects, ats, learning, assets, procurement, and sales.Setup, permissions, routing, labels, and behaviour.
Runtime/detailEnabled apps affect menus, launchpad, permissions, reports, module settings, usage, and available workflow namespaces.Testing the live experience users actually see.

Configure it

  1. Confirm the audience for this surface and whether they are staff users, portal users, customers, public visitors, or administrators.
  2. Open the owning product route: Global settings opens at /global-settings; launchpad Manage apps appears on /launchpad for users with settings permission.
  3. Review the configuration route and permissions before changing live behaviour: Tenant apps include tasks, finance, hcm, attendance, payroll, inventory, shopbyantly, tickets, documents, omnichannel, projects, objects, ats, learning, assets, procurement, and sales.
  4. Define the primary records, fields, statuses, owners, and notifications involved in this workflow.
  5. Configure Tenant app, Launchpad app tile, and Module setup first because they shape the rest of the rollout.
  6. Add Permissions and Shortcut only after the core path works with sample data.
  7. Test the runtime surface as a restricted user, not only as a superadmin: Enabled apps affect menus, launchpad, permissions, reports, module settings, usage, and available workflow namespaces.
  8. Check downstream connections after saving: Tenant apps connect marketplace subscriptions, launchpad layout, module data, namespace permissions, usage logs, and onboarding.
  9. Record the owner, rollout date, and support path for the configuration.
  10. Review the first week of activity and remove any option that users do not understand or need.

Configuration options

OptionUse whenNotes
Tenant appA module should be availableEnable in marketplace or app management.
Launchpad app tileUsers should open it easilyManage from /launchpad.
Module setupThe app needs configurationUse the module settings pages.
PermissionsOnly some users should use the appConfigure roles and namespace rules.
ShortcutA page or object should appear beside appsUse launchpad shortcuts.
Disable appModule should be hidden or retiredCheck data and integrations first.

Operating notes

  • Keep labels aligned with the words users see in the product, especially Tenant app and Launchpad app tile.
  • Permissions still matter even when a menu, page, or link is visible.
  • If users see empty data, check role filters, enabled apps, ownership rules, and saved filters before editing records.
  • If a change affects customers or public visitors, test from a logged-out or customer account as appropriate.
  • Use reports or logs to confirm the change produced the expected operational result.
  • Capture configuration decisions in rollout notes so support teams know what changed.
  • Do not reuse one option for unrelated processes just because it is already configured.
  • Review linked notifications, workflows, dashboards, and reports after changing this surface.
  • Prefer narrow changes that can be tested with sample data before a tenant-wide rollout.
  • When troubleshooting, start at the route users open, then inspect configuration, permissions, and logs in that order.
  • Keep retired settings hidden or archived so users do not choose outdated paths.
  • Assign an owner for ongoing review; unattended configuration becomes stale quickly.

For developers

Use these pages when the surface is read or changed by code, scripts, embeds, widgets, API clients, webhooks, or realtime listeners.