TechAppForceEvery query knows who is asking.
Access is set per role, per entity and per operation, and the platform applies it to every read and write.
Every request, checked in order
- Sign-inPassword, one-time code, MFA or a company Microsoft account
- RoleWhat this person may do in this app
- ScopeNone, Own, Team or All, per entity and operation
- Rows returnedOnly the records the scope allows
- Change historyWho changed what, and when
The problem
The plumbing every team rebuilds, and fears getting wrong
One missed filter and a customer sees data that is not theirs.
- Design sign-in, roles and row-level rules
- Review and maintain every line
- Every developer must remember the filters
- Keep patching as enterprise customers ask for more
- Tenant, app and environment travel with every request
- You configure the roles
- The platform decides access on every read and write
- No filters to remember in each query
How we solve it
Set the scope once. Every read and write obeys it.
None, Own, Team or All, per role. Screens, reports, APIs, workflows and TAFI all get the same rows.
- Support agentNoneNo deals at all
- Sales repOwnOnly their own deals
- Sales managerTeamEvery deal in the team
- FinanceAllEvery deal in the app
What you set
One setting per role, per entity
Change a role's reach later as a reviewed release, not a code change across every query.
| Role | Deal | Invoice | Payroll |
|---|---|---|---|
| Sales rep | Own | Own | None |
| Sales manager | Team | Team | None |
| Finance | All | All | None |
| HR | None | None | All |
- WorkspacesAccess through membership, flowing to related records.
- Record sharingOne record to a user, team or role.
- Rule-based filtersStored conditions per role.
- Screen permissionsHide or disable components per role, on the server.
Sign-in
Sign-in your customers expect, with rules per tenant
Each tenant's administrator connects its Microsoft organisation and sets its own security policy.
- 1 Password One-time code Company Microsoft organisation
- 2 MFA: authenticator app or email code
- Signed in. Refresh tokens rotate on every use.
- Require MFA
- Password complexity and expiry
- Account lockout
- Token and session lifetimes
- Email confirmation
OAuth 2.0 and OpenID Connect for integrationsNot available yet: SMS codes and passkeys, user invitations, field-level security
Selling to many customers? Tenants, self-registration, subdomains and billing are on Build SaaS.
Proof
Access says who may change it. History shows who did.
Change history is on by default, including approvals and soft deletes.
- Created the invoicePriya S. · 2 Sep, 09:14
- Amount 4,200 → 4,800Priya S. · 2 Sep, 11:02
- Status: Draft → SubmittedPriya S. · 3 Sep, 10:30
- ApprovedFinance · 4 Sep, 16:45
- Removed (soft delete, still on record)Arjun M. · 9 Sep, 08:12
Is the scope checked in the browser or on the server?
On the server. Screens and client SDKs can ask what a user may do in order to show or hide buttons, but the platform applies the role’s scope to every read and write.
Can our customers manage their own users?
Yes. A tenant administrator manages its users, assigns roles and connects their company Microsoft organisation for sign-in, without a request to your team. User invitations are not available yet.
Do you support SAML or on-premises Active Directory?
Not today. Sign-in options are password, one-time code, multi-factor authentication and a company Microsoft organisation. If you need another identity provider, tell us early so we can discuss it honestly.
Do you hold security certifications?
We do not claim certifications we do not hold. Send us your security questionnaire and we will go through it with you. See security.
Walk through your access model with us
Tell us how your users and roles should work. In a demo we show the access settings and sign-in working together.