# Apps, publishing and permissions > Build in Chat, reopen your automatically saved Apps, and choose who can use them. Apps are being introduced in stages. This guide describes the controls as they become available in your workspace; it does not mean every App feature is enabled for your account. ## Build in Chat and return to Apps Describe the App you need in Chat, including the data you want to use. Chat can ask questions in the same conversation. To work from a file, attach it to the chat and explain what its rows mean. Try the App in the canvas, then ask for a specific change in that conversation. While Chat works, short updates explain what is happening. Consecutive steps appear in a compact summary that you can expand. The canvas opens the App as soon as its first preview is available. Before that, it shows a building state; during later changes, the existing App stays visible until the update is ready. **Activity** remains available as a secondary tab. Where the build progress controls are available, an App card appears in the conversation when the first preview is ready and updates as the same App changes. A live status line shows the current work. After a build, selecting a suggested next change sends it immediately. To revise the wording first, type your own request in the composer. Product photos that an App shows from public web addresses load from the App itself. Poneva fetches each photo, resizes it and, when the site allows caching, keeps a copy for your company, so a gallery shows its photos quickly the first time and almost at once when you open the App again. Chat's own checks of the App and the picture on its card show the same photos. A photo the site changes or removes can keep showing for up to 30 days. When someone loses access to an App, photos their browser already shows may stay cached on that device for up to 30 days, and Poneva stops fetching new photos for them within a few minutes. The first successful preview saves your App automatically, privately to you. A confirmed save identifies the App and its version. There is no Save App step. Later builds become versions of the same App; changing its audience is a separate choice. Open **Apps** beside Library in the sidebar. **All**, **Mine** and **Shared** show the Apps available to you. Apps are separate from Library, which holds documents, reports, decks, sheets and charts. Each App card shows a preview or App icon, its name, updated time and audience; shared Apps also name their owner. Select a card to open the App. If there are no Apps yet, choose **Start in chat**. If saving is unconfirmed, keep the original attempt and use its available status check before trying again. If opening fails after saving succeeds, retry opening the same App. Saved refers to the App version; entries inside it have their own saving status. A session-only change is not a saved entry. A saved App opens as its own full page under one top bar, on a computer and on a phone, with no workspace sidebar beside it: a way back to Apps, its name and icon, and its actions. The available Share control shows its current audience. It is not labelled as an Artifact or wrapped in a chat-thread panel. For an App you made, **Change with Chat** reopens the chat you made it in, with the App beside it on a computer, or as a sheet on a phone; if that chat is no longer available, the page says so. While an App opens, its page shows the App's picture or name with a quiet progress line; if it cannot open, the page says so and offers **Try again** when that can help. The normal Chat canvas remains available while building or changing it. You can also ask in another personal chat to find an App you saved by its name or description and open it there. Chat searches your current saved Apps and opens the chosen one in the editing canvas, where it can read the source or take a screenshot. Opening builds a working preview; it does not save a new version or publish. If that chat already has unsaved App files, they are retained separately before the chosen App is restored. An outdated selection or withdrawn source permission must be resolved before opening. Open Sources, Versions or History when you need those details. Ask Chat to copy an existing App and tailor the copy when you want to reuse it; review the copy's data and permissions before publishing. New Chat and the landing page include App examples alongside Artifact and research examples: track competitor prices with images, work with a connected sales database or your team's weekly numbers, and build a quick team quiz. Choosing an example in Chat sends it immediately. Ideas selected from the Apps page open a new Chat with the wording ready to review and send. ## Use your images in a deck Attach a screenshot, logo or photo to the personal chat and ask Chat to place it on a slide. Chat can import the actual uploaded image into the deck; you do not need to host it at a public URL. The imported copy is sized for slides, preserving its proportions and transparency, while the original chat attachment stays unchanged. The image is saved with the deck's editable files and built output. Reopening, editing and exporting the saved deck to PDF or PowerPoint use those retained files. Its viewers follow the deck's existing access permissions. If an image is unsupported or exceeds the import limits, Chat reports that it could not import it. ## Choose who can use, edit and publish The **Only you ▾** chip in the canvas opens Share. Choose **Only you**, everyone at your company or specific people. Your App starts private; saving it does not give other people access. An App's current permissions determine what each person can do. | Permission | What it allows | | ----------- | -------------------------------------------------------------------------------------------------- | | Can use | Open an App shared with you and use the data and actions currently allowed for you. | | Can edit | Change the App and save a version, with current data and field permissions still applying. | | Can publish | Publish an exact reviewed version when company publishing policy and the required Checks allow it. | A company administrator does not automatically gain access to another person's private App. Sharing an App does not automatically share every source, private field or external action. Access is checked again when the App is used. ## Review the version you publish Publish shows the version, changes, permissions and required Checks. A newer draft does not change the version other people use. Complete the required review of data changes, access changes and source consent before confirming publication. Publishing does not grant permission to write to a connection. Set up that connection's write access separately. Publishing with an enabled schedule starts that App's own collection history on the company's budget. Activation needs a person's explicit consent and current access. Imported history must come from retained, authorized source data; a schedule does not create older observations that the source never held. Publication Checks scan the exact saved source for secrets and dependency risks. A source or scan-policy change can require a fresh scan. A screenshot or visual review does not replace these scans. Publishing through an authorized coding agent follows the same current permissions and required scans. If a reply is lost, use the available status check for the original attempt. An unknown result or missing receipt does not mean nothing happened. Keep that attempt and avoid starting another publication while its result is uncertain. ## Choose how each source is read Company policy controls which source modes are allowed. Within that policy, the creator chooses a mode for each source before publishing. | Source mode | What viewers use | | ------------------------ | ------------------------------------------------------------------------------------------------------------------------- | | Owner's connection | The consented connection, limited to the queries fixed at publication. This is the default when company policy allows it. | | Each viewer's connection | That viewer's own eligible connection. A viewer who can obtain access sees **Connect** when a connection is missing. | Viewer mode never falls back to the creator's or publisher's connection. If policy does not allow the default, choose an allowed mode explicitly. A broader company policy does not silently broaden an existing App's saved queries or source choice. Revoked access blocks the affected source and clears its cached data and evidence. **Connect** is offered only when connecting could authorize the read; a policy refusal may require the creator or administrator to act. Unrelated authorized sources can remain usable. Re-enabling access requires current authority and any fresh consent; old cached rights do not return automatically. ### When a database read takes too long Closing or reloading an App cancels its pending database reads. Other people’s reads continue. This applies both to previews and saved Apps. An App's database read gets the same time as a read in Chat: 30 seconds unless the company allows longer for that database (see **How long a database read may run** in the Poneva Chat guide). When a read stops early, the App learns why: it ran out of time, the database's replica cancelled it, the database was busy, or the database could not be reached. The App can show that instead of an empty screen. Poneva does not send a slow read again by itself. While you build an App in Chat, Poneva can see how its data reads went in your preview: how many worked, and why any failed. It uses this to fix reads that fail, for example by narrowing a heavy query. ## Allow writes once for each connection The first write in Chat asks **Allow Poneva to write to {connection}?** Approving changes your access to **Read & write** for that connection. Later permitted writes use that access without asking again. On a company connection, a company administrator can approve write access for its stated audience. Approval never applies to every connection or person. For an App or agent, the owner approves the connection's write use once during setup. Its later runs use that permission. The decision names the connection and person or audience it covers; it cannot approve a changed scope or substitute a different account. Use **Edit access** to choose **Read** or **Read & write** at any time. Revoking write access applies to the next call, including a pending action. Every write is recorded in the audit trail. Sharing an App and allowing it to use a connection are separate choices. If an approval or write reply is lost, keep the original attempt and use **Check status** when available. A missing receipt or unknown result does not prove nothing happened. Check the original result before submitting another action; status recovery does not perform the write again. ## Unpublish, restore or duplicate **Unpublish** stops ordinary viewer access across the App's published history. It keeps the App's entries and history. Authorized editors can still inspect through a fresh editor access check. Republishing does not revive old viewer access tickets; people need a new authorized load. **Undo** appears only when a verified, currently authorized restore point exists. Its description tells you what it restores. Otherwise, use **Restore…** when available. Restoring an App version and restoring or resetting business data are separate decisions with their own review. **Duplicate** creates a new private App. Its collections start empty unless you explicitly review and request an allowed copy. Sharing, source consent, credentials, schedules and webhooks are not copied as standing authority. Review the new App's source choices and permissions before publishing it. If copying has an uncertain result, check the original attempt rather than submitting a second copy.