Build an internal app

Describe the workflow#

An internal app gives people and agents a shared place to do a kind of work inside Opser. Describe the users, records, steps, views, and access rules. Include the actions you want the agent to perform through tools.

Build an equipment checkout workflow. Track assets, borrowers, due dates, and returns. Staff can request a checkout; coordinators approve it. Include an overdue view, search by asset tag, and agent tools for finding and returning equipment.

The agent should inspect installed apps before deciding to create a new one or edit an existing app. A dashboard may be enough for an overview. App building needs to be enabled in your environment; if the builder reports it is unavailable, ask your administrator about that capability.

Review a draft with separate data#

The agent creates or opens a draft and works on its source files. The draft has a live preview and version history. Its database sandbox contains the business schema without production records; use synthetic examples to exercise the workflow.

Edits rebuild the draft preview. Review the real screens, navigation, forms, required fields, empty states, error handling, and mobile layout. A preview is separate from the installed version your team uses.

Build the agent and app interfaces together#

Ask for useful tools and skills alongside the screens. The human action and agent action should apply the same validation and business rules. If the app connects to another app, specify its contracts, events, and notifications.

Test with the intended permissions. Check a normal workflow, an invalid request, and an attempt to access a record the user should not see. A polished screen alone does not verify the app's behavior.

Test and install the reviewed version#

The builder runs tests and readiness checks over the source and declared platform capabilities. These include permissions, resource bindings, tools, data ownership, and the app's declared connections. Resolve blocking feedback and review the preview before installing.

An authorized user can install the reviewed draft into the workspace. A user without installation permission can submit an installation request for an administrator to review. Installing an edit upgrades the existing app; it does not create a second copy.

Who can change an app#

Everyone with access to an installed app can use it. Only the people on its list can change it. The person who first publishes an app becomes its owner, and Settings → Apps shows the owner on the app's row. Select People to see the list. The owner can add editors, who can change and publish the app, remove them, or make someone else the owner.

When the owner is not available, an admin can open People and select Take ownership. The previous owner stays on the app as an editor, and the change appears in activity.

Agents follow the same list. If you ask your agent to change an app you are not on, it tells you who owns the app so you can ask to be added.

History and ongoing changes#

Ask for focused changes and inspect the diff or history when reviewing an update. Restoring an earlier draft source creates a new source revision and rebuilds its disposable preview data. It does not roll back production business records.

When another update has changed the installed app, the draft may need to be reconciled with that newer version before installation. Preserve the newer behavior as well as your intended customization.

Use Settings → Apps for installed apps, work in progress, and operation history. See app management for lifecycle details.