Use this guide to control who can use an App, change its settings, and review its activity. For building and publishing, start with Get Started with Apps. To move an App between accounts or installations, see Copy and Move Apps.
Open Apps, then select an App. Use the left navigation, or App view on smaller screens. Editable Apps have Builder and Commits. Imported copies and serving environments show Data & actions and Versions; edit the source in your development environment, then import an updated package. You can still manage access, secrets, write actions, and published versions here.
For an editable App without AI building, change source through its repository or a connected assistant. Use App settings > Repository > Build to build repository changes.
Access and security
Choose Access under Advanced settings for a new App, or App settings for an existing one. Changing an existing App's access requires publish permission and applies to live traffic as soon as you save.
| Mode | Who can open the live App? | Data access |
|---|---|---|
| Knowi sign-in required | Knowi users in the App's account who own it, have been given access, or are account administrators. | Each viewer's Knowi permissions and row-level restrictions apply. |
| Public | Anyone with the URL. | Selected datasets use an App-level grant, checked against the publisher's current dataset access and content filters. |
| App manages access | Visitors allowed by the App's own login system. | Visitors have no Knowi identity. Data access uses the same App-level grant as Public Apps. |
New Apps default to Knowi sign-in required when App sign-in is configured. Otherwise, that option is disabled and the form selects Public. Check before publishing: Public allows anyone with the live URL to open the App without signing in. Ask your administrator to enable App sign-in if you need Knowi accounts.
For Public and App-managed Apps, treat selected datasets as data the App may expose to every allowed visitor. Private dashboards and actions that require a Knowi identity still require Knowi sign-in. Selecting App manages access does not create a login system; the App must provide one.
Apps are isolated from other Apps and accounts. App code does not receive your Knowi browser session or datasource credentials. Store third-party API keys under App settings > Secrets, never in prompts or source. See using secrets in code.
Share an App
In the Apps list, open the row's ... menu and select Share.
- Inside Knowi, sharing lets recipients find the App. Full access lets them edit it, subject to their App permissions. Lower access levels are view-only. Publishing and sharing require their own permissions.
- On a live Knowi sign-in App, sharing grants App access to those users or groups. They also need access to its data. Sharing an App does not share its datasets or dashboards.
Public Apps remain available to anyone with the URL. App-managed Apps use their own login rules. Knowi's Share dialog does not restrict those visitors.
New Apps use the creator's auto-share groups, if configured. The management list shows only Apps you own or that are shared with you, even if you are an administrator. Account administrators can also open live Knowi sign-in Apps.
Share App code
For an App with a Knowi-managed repository, account administrators who can edit Apps can give GitHub users access to its code. This is separate from sharing the App: it controls who can read or change the source on GitHub, not who can open the App.
Repositories you connected yourself, either GitHub or Other Git over SSH, are not shared from Knowi. Manage their access in GitHub or on your Git host.
- Open the App, then App settings > Repository. After you create an App with a Knowi-managed repository, this row opens on Share code if nobody has access yet.
- Under Share code, enter the person's GitHub username.
- Choose Read only or Read and write. Read only lets them view and download the code; Read and write also lets them push changes. Read only is selected by default.
- Select Share.
You can also add people while creating the App. After you select Create repository under New app > Advanced settings > Repository, Manage access works the same way, starting on Read and write.
GitHub emails the person an invite, and their entry shows Invite pending until they accept. After they accept, they can open the repository and download it as a ZIP. To remove access, select Remove next to their name.
The list is read from GitHub, so it also shows access that was changed there directly. If Knowi cannot read it, an error appears instead of an empty list.
The Repository row also has Open repository and Download ZIP for repositories hosted on GitHub, including Knowi-managed ones. Open repository opens the repository page. Download ZIP downloads the code on the App's connected branch. For a private repository, GitHub asks the person to sign in, and they can open it only after they have been given access.
Show an App in the Knowi menu
For a live App, open App settings > Knowi menu, select Show this App in the Knowi menu, and save. You need publish permission and write access to the App. The entry appears on the next page load and opens the App inside Knowi.
For Knowi sign-in required, the entry appears for people the App is shared with and account administrators. They still need permission to its data. A Public App's entry appears for everyone in the account. App manages access is not supported because Knowi cannot sign its viewers in.
Choose a Menu icon to help people recognize the App. Entries are ordered by App name. Up to three appear separately; more than three are grouped under Apps. Turning off the setting, unpublishing the App, or switching to App manages access removes the entry.
Settings
Open App settings and expand a row. Available options depend on your permissions and the installation. New App setup is under Advanced settings.
| Setting | Use it to |
|---|---|
| URL & domain | Change an unpublished App's URL slug or attach a custom domain. |
| Access | Choose who can open the App. Changes apply immediately. |
| Repository | Choose the source for a new App, inspect its branch and commit, open the repository or download its code as a ZIP, share a Knowi-managed repository with GitHub users, or select Build after changing source. Imported copies have no source here. |
| Database | Add managed storage for the App's own records, where available. |
| Embedding | Allow selected websites to display the published App. |
| Knowi menu | Show the live App in Knowi's left menu. |
| Secrets | Save API keys used by the App's server. Publish again to apply changes. |
| Write actions | Open saved database actions in App resources. |
Settings save separately from source code. If a change needs new code, build and publish that change too. For example, adding storage does not add a form that uses it. In Builder, Build changes can use an empty prompt to describe pending resource changes; name changes still need a request.
Use the pencil beside the name to rename the App. The slug can change until first publication; changing it breaks links to the old address. Use a custom domain for a different live address after publication.
App actions are at the bottom of App settings:
| Action | What it does |
|---|---|
| Republish live version | Reapplies the current live version, including changed secrets. It appears for a live App and requires publish permission. It does not publish the version you are previewing. |
| Scheduled reports | Opens the App's reports. |
| Export to another account | Downloads a file to import into another account on the same Knowi server. Requires edit permission. See Export a package. |
| Export to another server | Downloads a signed ZIP to install on a separate Knowi server, including on-premises. Requires edit permission, and appears only when your administrator has set up package signing. |
| Remove app | Takes the App offline immediately. Requires delete permission, and you type the App's slug to confirm. Versions and history remain for administrator recovery. Git history remains, and a Knowi-managed repository is archived when no App uses it. |
Both export actions are also in the Apps list ... menu.
Attach design references and brand assets
Use Design reference in the Builder composer or + Upload under Brand assets in App resources. Dropping an image onto the composer adds a design reference.
| Type | Purpose | Limits |
|---|---|---|
| Design reference | A screenshot, mockup, or style sample for the next generation. It does not become an App file. | PNG, JPEG, or WebP, up to 4 MB each. |
| Brand asset | A logo or image saved with the source for use in later versions. | PNG, JPEG, WebP, or SVG, up to 1 MB each. |
Use up to four of each kind per generation, totaling 8 MB. Each App can hold up to 12 unused uploads totaling 24 MB; remove unused images before uploading more. For example: "Use the attached logo in the header and its colors for the buttons."
Successfully uploaded images waiting for a build remain after you reopen an existing App or retry a failed generation. After success, design references leave the composer and brand assets show In the app.
Remove removes an unused attachment, not a file already in the source. To replace a saved logo, upload its replacement as a brand asset and request the change. To remove a saved image, request a source change. Reattach any upload that failed. See image validation and file paths.
Sign-in branding
For a Knowi sign-in App, ask the Builder or your developer to use the App's name, logo, and colors on its sign-in and MFA pages. For example: "Use my attached logo and the App's blue buttons on the sign-in page too."
The sign-in logo must be no larger than 64 KB. Review and publish the updated version to apply branding. Developers can edit the branding declaration.
Optional managed App storage
Keep No database when the App only reads Knowi data. Where available, Managed PostgreSQL stores the App's own tasks, notes, approvals, or preferences.
Choose it under Advanced settings > Database for a new App; Knowi provisions it during generation. For an existing App, open App settings > Database, select Managed PostgreSQL, then Provision Database. The panel shows status and the applied schema version.
Where backups are enabled, Knowi takes nightly backups. Back up now creates one for a Ready database. Knowi also backs up before revoking storage or deleting an App and stops that operation if the backup fails.
Where restore is enabled, select Restore beside a backup. The App must have no published version. Restore replaces the current database after backing it up. If it fails after replacing data, keep the App unpublished and contact Support or restore the backup taken just before the operation.
To revoke storage, choose No database, then Save. This removes runtime access without immediately deleting records. The panel shows the deletion date, normally 30 days later. Back up or provision again before that date.
Preview does not use the live managed database. Publishing or rolling back code does not erase or roll back saved records. Copy packages do not transfer these records; see Copy and Move Apps.
Write actions
A write action lets an App add, update, or delete one record in your SQL Server database. An authorized editor saves the SQL in Knowi; the App supplies values. Users do not see the SQL or receive database credentials.
Write actions require Knowi sign-in required and DBWrite enabled for the account. Contact your account manager to enable DBWrite. Any signed-in user with access to the App can run its enabled actions, including deletes. There is no separate action audience. Use App sharing and the saved SQL's user restrictions to control access.
To set up an action:
- A datasource administrator enables Writable Destination on the SQL Server connection. Only SQL Server is supported.
- In App resources, select + New under Write actions. Imported Apps use Data & actions. Name the action, choose a database you may edit, and enter one SQL statement. Write values as
$c9_orderId$, without quotes. Set each value's type and rules, then Save. Saving validates the statement; it does not run it. - For an editable App, ask the Builder or your developer to add a button that calls the action. Build, preview, and publish. For an imported App, configure the action name its existing buttons expect.
Name the app uses is a stable key such as approve-order. It accepts up to 64 letters, numbers, periods, underscores, and hyphens and cannot change after saving.
Values come from either the form or the signed-in user:
-
From the signed-in user:
user_id,user_username,user_name,user_timeZone, and names used by customer, group, or user filters. The App cannot supply or override them. Filter values must resolve to one enabled Equals value for the person; missing or ambiguous values block the action. - From the form: all other names. Choose text, integer, number, or boolean. Under Rules, make a value optional or restrict allowed values, number ranges, or text length. Use another name if a form value would otherwise match a filter field.
Use one INSERT ... VALUES, UPDATE ... WHERE, or DELETE FROM ... WHERE. Exactly one target row must change. Zero rows returns a conflict; more than one rolls back and fails. Include the record's ID and a trusted user or tenant value in the condition. A version check prevents overwriting someone else's concurrent edit. Database triggers and cascading deletes may affect additional records.
Saving, disabling, or deleting an action changes the live App immediately. Adding a required form value may also require a new App version to send it. Deleting an action breaks buttons that call it. Where a value comes from is decided when you save; save again to apply a filter field added later.
Preview returns a dry-run result without writing. View as sessions cannot run writes. A live run checks current App access, the saved action, its author's permissions, and Writable Destination. Turning off Writable Destination blocks new runs but cannot undo committed changes. Limit the database login to the tables and operations required.
After a conflict, reload the record before retrying. An unknown outcome means the database did not confirm the commit; check the record before retrying. See SQL examples and developer rules.
Review write activity
Open App activity and select Write actions to inspect the action, outcome, user, time, request ID, and rows affected. The same knowi.write records appear in the App Events dataset, subject to its normal data permissions.
The account event log records runs as App Action Execute and configuration changes as App Action Configuration. These entries contain identifiers, not SQL, input values, or record contents. Recording happens in the background and can lose events during overload or failures.
Reports from an App
An App can email or schedule reports of its own pages. Ask the Builder or your developer for Email this report or Schedule delivery. Knowi handles delivery, so a schedule keeps running after the page closes.
Reports appear in Reports with an App chip. To filter to one App, open App settings > App actions > Scheduled reports. Edit recipients, delivery actions, or schedules there, or pause, resume, and delete reports. Only the App can change which page is attached.
This requires a Knowi sign-in App and a viewer with permission to view the App, create reports, and send email reports. Reports use that person's current data permissions and the version published when they run. Public and App-managed Apps cannot send reports. Preview neither sends mail nor saves schedules. See report actions for developers.
Embed an App in your site
Open App settings > Embedding, enable Allow this app to be embedded, list allowed sites, and save. You need edit and publish permission. Only listed sites can frame the App.
Select Copy for the integration snippet. Public Apps use an iframe. Knowi sign-in Apps need your portal's developer to provide a Knowi single sign-on token for each viewer. App-managed Apps cannot be embedded. Embedding grants no additional App or data access.
Publish first if the App is not live. On live Apps, embedding settings apply when saved. If the panel reports an older runtime, select Republish. Some browsers block sign-in inside a frame on another site; an App custom domain under the portal's domain avoids that issue. A Knowi dashboard inside an App cannot display when the App itself is embedded.
See embedding setup and code for allowed-site rules, tokens, and browser behavior.
View app as a user
Select View as... in the App header, or View as user... in its Apps-list ... menu. This always opens the published version, which the dialog identifies, regardless of the version being previewed. The App must be live and use Knowi sign-in.
Account administrators, Knowi support administrators, and users with user:login-as can use this feature, subject to App access and Knowi's login-as rules. The dialog groups people under You, Has access, and No access to this app. Search by name or email, then choose Open as [name]. You can select a user without access to check the access-denied page.
The App opens in a new tab without another password or MFA prompt. A banner identifies the selected user; queries use their permissions and filters. Viewing another user is read-only: state saves, write actions, reports, and outbound requests other than GET and HEAD are blocked. Custom events are not recorded. Open as yourself uses your own permissions with full access.
Exit clears the App session and returns to Apps. The session expires after 30 minutes. Your Knowi tab keeps its identity, but other tabs on the same App domain share the selected user's App session. Signing into an App through Knowi's login-as feature has the same restrictions.
An App Login As audit entry records the App, selected user, and operator. Account-admin entries appear in the customer's audit log; support entries belong to the support operator's account. Impersonated sessions are excluded from App usage analytics.
App activity and custom events
Open App activity to review all versions. Choose Last 24 hours, Last 7 days, or Last 30 days, then filter by event type. The page shows up to 100 matching activities. Its counts describe those displayed activities, not all usage in the period.
Related request, data-access, and write records are grouped by request ID. A group shows a result such as Completed, Conflict: record changed, or Access denied. Expand it for recorded details. Older records without a shared ID stay separate.
Published Apps record page views, request errors, and use of Knowi features. After the first live batch, Knowi creates App Events - <App name> in the owner's account. Use this dataset for broader analysis, dashboards, reports, or alerts, and share it only with people who should see the records.
Knowi sign-ins shows successful sign-ins and its own count, including password/MFA, SSO, and existing Knowi sessions. These records do not need an App Events dataset and are not copied into it.
Ask the Builder or your developer to track business actions, for example: "Track when someone exports the sales results." See custom event code and limits.
Preview, authenticated PDF rendering, and View as sessions do not record usage events. Anonymous PDF renders of Public Apps can count as page views. Events can be lost during overload or failures; use them for usage analysis, not as a complete audit record.