An app can display information, accept input, and store records when it is built with persistent data. Explain these requirements when creating the app so the result matches the work it needs to support.
Define what to store
Describe the records, required fields, and relationships in ordinary language. Include who may read or change them. For example: “Each incident needs a title, severity, owner, and status. Team members can submit incidents; managers can close them.”
Provide representative sample data and state whether it is only for testing. Ask the builder to distinguish a demonstration from a working data-backed flow.
Test persistence and permissions
Create a test record, refresh the app, and confirm it remains. Open the app with another authorized user to verify the intended visibility. Try a permitted edit and check the result.
Do not assume an attractive table is connected to live data, or that sharing the app grants access to every underlying record.
Connect ongoing work
Agents and automations can support an app's work when the app exposes the necessary permitted capabilities. Describe the desired connection and verify the authorized account and data access. An app appearing in your list does not mean every agent can perform every operation inside it.
Change the data structure carefully
Explain how existing records should be handled when adding fields or changing their meaning. Switching to an earlier app version does not automatically restore earlier data.
See updating apps and Automations.