Rules live in the browser
When the business rule is a line of generated client code, anyone with the data connection can skip it, and nobody can prove it ran.
Renly Apps
Apps your team works in. Rules the server enforces.
Describe the tracker, register or CRM you need and an agent builds it on your own data. Every change is checked against the app's write rules on the server, the ones that need a person wait for one, and each one leaves an evidence record. Agents work inside the same rules.
The problem
Apps built in chat are easy to make and hard to govern
AI assistants can now turn a sentence into a working app with a data store behind it. That is useful, and it moves the business rules into places nobody governs: the generated code, the person's own write access, and a log that says an app was created but not what it did.
Writes go straight through
A write made as the signed-in person is just a write. There is no step where a second person sees the change before it lands, and no way to require one.
The log says an app was made, not what it did
Lifecycle events get audited. The reads and writes inside the app, and which version of the app made them, do not.
The artefact
One change, one record, one decision
A write rule in a Renly App says which changes need a person first. When one matches, the change is not applied. It becomes a request that carries the exact change, the rule, who asked and who may decide, and it waits in the app, the Approvals inbox, email and Teams.
Write request
Request tracker, version 3
Waiting for approvalApprovals over $5,000 need the finance lead. Expires in 7 days.
Change
- Record
- REQ-1042, Replace the lobby printer
- Action
- update
- Fields
- status
triaged→ approved - approved_amount
empty→ $6,480.00
Who
- Requested by
- Procurement agent for Dana Lee
- Approvers
- Finance lead (1 of 1 needed)
- Rule
- approvals-over-5k
When it is approved
- Runs
- Exactly this change, as the requester, if the record has not changed since
- Recorded
- App version, interface, rule, approver and the fields before and after, sealed into the evidence trail
Approve
Reject
Open in Renly
Illustration with representative values. The sections are the ones a request carries in the app, in the Approvals inbox, in email and on a Teams card.
What every held change carries
Approvers see the same thing wherever they decide, and the decision runs the stored change, not a fresh one.
- The exact change. Field by field, before and after, with a digest so what runs is what was approved.
- The rule that held it, with the message its maker wrote, so the approver knows why they are being asked.
- Who asked. A person, an agent acting for a named person, an API key, or an import held as one request.
- Who may decide. A role or named people, never the requester. Two-person rules need two different approvers.
- What happens on approval. The change is applied as the requester with the approver recorded. If the record moved on, the request fails as stale rather than overwriting it.
- Where it goes. The Approvals tab in the app, the Approvals inbox, signed email links and Adaptive Cards in Teams. Requests expire after 7 days.
How it works
Every write takes the same path, whoever asks
A page never sends a query. It names a component of the published app and the server runs it as the viewer, with their row scope and field access. A write, from a page, an agent, the REST API or an import, goes through the Records service and the app's rules before anything changes.
How Renly Apps differ
Built on Records, governed like everything else in Renly
An App is one versioned definition: a data model, pages, roles, write rules and data sources, published together and rolled back together. Records is the data platform underneath, so apps inherit the roles, approvals, evidence and agents Renly already has.
1
Rules on the server
Pages are declared, not coded: fifteen components, a closed query grammar with 25 conditions and 11 operators, and declared actions. The server validates every reference on save and publish, and runs every query and action as the viewer.
2
Approvals on writes
Per-app rules by type, action, fields and conditions: approval, two-person or deny. They hold a person's write, an agent's write and an API write alike, and the approver sees the exact change wherever they decide.
3
Evidence for every change
Every applied write is a Records event with the actor, the app version, the interface, the rule and the approver, linked into the organisation's sealed evidence chain. Writes to live sources are audited and sealed too.
4
Agents inside the same rules
The App Builder drafts an app from a brief and publishes through an approval card with the diff. Agents working in an app's data use the same roles and field access as the person they work for, and Pause all agents stops them writing.
5
The viewer's own data access
Field access per role: hidden, masked or read only. Live Dataverse, Salesforce, SharePoint Lists, Excel tables and read-only SQL are read through each viewer's own connection, so sharing an app never grants access to data.
6
An inventory for admins
Every app with its owner, version, rules, pending requests and 30-day writes. Pause an app and every write is refused while reads continue; change its owner when someone leaves; export its definition. Each action is audited.
What is in an app
Everything a team needs to run a process, in one versioned unit
Data model
Record types with text, number, date, yes or no, choice and lookup fields, a sensitive flag, owners and versions. Up to 100,000 records on Pro Plus; unlimited on Enterprise.
Interfaces
Up to 10 interfaces of 30 pages each, for different audiences. Tables, boards, lists, forms, detail, related records, metrics, charts, timelines, text, actions, calendars, maps, reports and custom blocks.
Roles and access
Capabilities per role, a row scope of all or own records, and field access per role. Interfaces, pages and actions can be limited to roles.
Write rules
Up to 50 rules per app: approval, two-person or deny, with approvers by role or name and a message for the person whose change is held.
Data sources
Records by default. Up to 10 live or synced sources: Dataverse, Salesforce, SharePoint Lists, Excel tables and SQL, with a sync every 15 minutes to 7 days under the owner's consent.
Agents, automations and API
Record-change triggers into Automations, actions that run an automation, recommended plays, an App assistant through the API, a REST API with scoped keys, and signed webhooks.
Build with Teams in mind: an app is a channel or group chat tab, and approvals arrive as Adaptive Cards. The documentation covers every part, limit and status code.
Compared
Renly Apps beside app builders inside AI assistants
Microsoft 365 Copilot's app builders publish to the Copilot Managed Runtime, in public preview since 25 September 2026. It is a capable way to make a single-page app on Microsoft data. The comparison below is about governance: where rules run, whether a write can wait for a person, and what is recorded.
Renly Apps
App builders inside AI assistants
Where business rules run
On the server, in the app's versioned definition. Pages name a component; the server runs it as the viewer.
In the generated app. Copilot Managed Runtime documents a single-page app in the browser with business rules in client code.
A person before a write
Per-rule approval, two-person or deny, for people, agents and API keys. Held changes wait in the app, the inbox, email and Teams.
Writes run through the host as the signed-in viewer, checked against DLP and connector policy at design, deploy and run time. No approval step on writes is documented.
The record of a change
Every applied write: actor, app version, interface, fields before and after, rule and approver, linked into the sealed evidence trail.
Purview audits lifecycle events such as create, publish and share. Data reads and writes are not audited, and the admin view does not show what an app executed.
Agents on the app's data
The same roles, field access, rules and approvals as people. Pause all agents stops them. The App Builder builds from a prompt.
Allow-listed Microsoft MCP servers (Work IQ, Outlook, Teams) inside apps. Calling agents or flows at runtime is not documented; apps, agents and workflows are separate pieces.
Access to data
Roles, row scope and field access on Records. Live sources through each viewer's own connection; sharing an app never grants data access.
App access is separate from data access, and connectors run as the signed-in user. Any allowed connector; the default allow-list is 18 Microsoft connectors.
Ownership and admin
Apps belong to the organisation. One inventory with pause, change owner and export; every action audited.
An admin inventory with health in the Microsoft 365 admin centre. Each app is a Git repo with preview and live deploys.
Where people use it
The web, Android and phone browsers, a Microsoft Teams channel tab, and approvals as cards in Teams.
The browser, at managedapps.cloud.microsoft. No native mobile or Teams host is documented.
Price
Included in Pro Plus (10 apps, 100,000 records) and Enterprise (unlimited), per seat.
Copilot Credits per call (0.1 credit per launch, read or write, plus build credits), or Power Apps Premium.
Facts about Copilot Managed Runtime are from Microsoft Learn, including its governance, security and licensing pages, as read on 15 October 2026. The runtime is in public preview with no general availability date, so this can change. Its predecessor, the App Builder agent, stops creating apps in October 2026 and retires on 30 November 2026 (Microsoft 365 message centre, MC1505609). Claude artifacts, Gemini canvas and the code-first builders differ again; none documents approval on writes or evidence per change.
Templates
Seven places to start
Each installs as version 1 with its pages, roles and write rules in place, and opens ready to use. Change anything in the designer, or ask the App Builder.
CRM
Accounts, contacts and opportunities with a pipeline board. Sales reps see their own deals.
Request tracker
Requests triaged and worked by a team, with approval before costly work starts.
Asset register
Every asset, who has it, where it is and its history. Staff see their own, without the cost.
Risk register
Risks rated and treated, with sign-off before a serious risk is accepted.
Incident register
Report to close, with severity, root cause and follow-ups, and sign-off on serious ones.
Onboarding tracker
New starters from offer to first month, with pay visible to HR only.
Approvals log
Decisions that need sign-off, with who decided, when and why.
Or describe your own
Tell the App Builder what the app is for and who uses it. It proposes a plan, drafts, previews and asks you to approve the publish.
Plans
Part of Pro Plus and Enterprise
Apps have the same entitlement as Records. Free and Pro see the templates gallery and an upgrade card. See pricing for every plan.
Apps
Build, install and use apps, with write rules, approvals and evidence.
Pro Plus and Enterprise
Caps
10 apps and 100,000 records per organisation on Pro Plus. Unlimited on Enterprise.
By plan
Live and synced sources
Dataverse, Salesforce, SharePoint Lists, Excel tables and SQL, through the connectors your plan includes.
Pro Plus and Enterprise
Microsoft Teams
The channel tab and approvals as cards in Teams, with the Microsoft 365 integration.
Pro Plus and Enterprise
REST API and webhooks
Scoped keys, OpenAPI, held writes as 202, signed webhooks with retries.
Pro Plus and Enterprise
Audit logs
Organisation audit entries for app actions, keys, webhooks, pauses and exports.
Pro Plus and Enterprise
Policy service, fail closed
The Governed Runtime's independent policy check on chat requests and automation steps.
Enterprise
Questions
Before you build
Who can build a Renly App?
Organisation admins build an app from a prompt with the App Builder agent, or install one of seven templates. Makers shape every part in the designer: record types, pages, actions, write rules, data sources and access. Publishing is a reviewed version, and rolling back is one action. Build an app.
Do agents follow the app's rules?
Yes. Agents read and write app data through the same roles, field access and write rules as people. A matching rule holds even an autonomous agent's write for approval, and Pause all agents stops them writing. Agents in apps.
Is this a replacement for Power Apps or SharePoint?
It is not meant to be. Renly Apps are for the trackers, registers and small systems a team otherwise keeps in spreadsheets and chat tools, where approval and evidence matter. Where the data already lives in Dataverse, SharePoint Lists, Excel or SQL, an app reads it there through each person's own connection, or syncs it into Records.
Which plans include Renly Apps?
Pro Plus (up to 10 apps and 100,000 records) and Enterprise (unlimited). The Teams channel tab and approvals in Teams are on the same plans. Free and Pro can browse the templates. Pricing.
Can we write our own code?
A custom block is your own HTML in a sandbox with no network, fed only by the queries, aggregates and actions it declares, run as the viewer. Outside the app, a REST API with keys and scopes and signed webhooks let your systems read, write and listen. Custom blocks and API and webhooks.
Can people outside our organisation use an app?
No. There is no guest or portal sharing. Everyone who uses an app is a member of your organisation with a role on the app. Limits and FAQ.
Build the tracker your team keeps asking for
Start a 14-day trial of Pro Plus, open Apps, and describe it. The App Builder proposes the plan, you approve the publish, and every change from then on is on the record.
Start a 14-day trial Book a demo