TechAppForce

Security

Security you can check, described honestly

What TechAppForce does today to control access and record changes, and what we do not claim.

Send a security questionnaireBook a demo
History: Purchase request PR-0142Illustration
  • Amount changed42,000 to 48,500 by Priya S.
  • Submitted for approvalStatus Draft to Submitted
  • Record lockedNo edits while it is under approval
  • Approved at level 1Arjun M., with a snapshot of the record
  • Viewed by FinanceRole scope: Team
Illustration. Every change and every decision stays on the record, with who and when.

The problem

Your customers will ask who can see their data

The same questions, from public forums where SaaS builders discuss them.

  • “making sure customer A never sees customer B data...you need to enforce checking it at the lowest possible levels”
    SaaS builder, developer forumPublic comment
  • “how will you do data isolation and ensure that one tenant doesn't accidently see/process another tenant's data?”
    SaaS founder, developer forumPublic comment
  • “conditions to access these data are not limited to RBAC, but also depend on the type of data and metadata”
    SaaS builder, developer forumPublic comment

How we solve it

Every request is checked before a record leaves

Tenant, sign-in and role scope are applied when records are read, whichever screen, report or API asks.

1 A request arrivestenant: acmeapp: Ordersenv: Production
2 Signed inPassword or code MFAMicrosoft organisation
3 Inside acme onlyAccess is resolved within the customer's tenant.
4 Filtered by role

What comes back

  • Order 1042 · owned by your teamreturned
  • Order 1043 · owned by youreturned
  • Order 1051 · another teamnever sent
  • Order 1060 · owned by your teamreturned
  • Another customer’s ordersnever sent

Every change is written to the record's history: what, who and when.

Roles, scopes and sign-in in detail

What you get

Every change leaves a trace. Production changes are deliberate.

History on every record, and app changes that move through environments you control.

Change history on every record

What changed, who changed it and when.

  1. Changed
  2. By whom
  3. When

Soft delete where you need it

A mistaken delete can be traced and reviewed.

Separate environments

Each with its own configuration, compared at any time.

  1. Development
  2. QA
  3. Production

Reviewed releases

See every change before it is applied.

How releases work

Guard rails in TAF Studio

One item at a time, after review. Studio releases go to QA only.

  1. Development
  2. QA
Dry run

AI changes previewed first

A dry run first, with the signed-in person’s permissions.

What we do not claim

The things this page leaves out, on purpose

We would rather lose a checkbox than win it with a claim we cannot back.

Not claimed

Formal certifications

Ask for our current status; we answer in writing.

Not claimed

SAML or on-premises directories

Tell us what your customers use.

Not claimed

Access finer than the entity

No per-field permissions or data masking.

Not claimed

Uptime figures

Discussed for your plan, not on a web page.

Your security review

Send us the questionnaire. We answer in writing.

Including where your app is hosted and how customers are kept apart.

  1. Send your questionnaire

    Your format or your customer’s.

  2. We answer in writing

    Question by question.

  3. We say what is not offered

    No surprises in contract review.

  4. A call with the engineers

    The people who build the platform.

Send a security questionnaireBook a demo