TechAppForce

Platform

See it work: five real changes, step by step.

Each walk-through starts with a request a customer might make and ends with a reviewed release. Each one also says where configuration stops and your team’s code begins.

Start free trialStart with a field

How It Works

Five changes, each from request to release

These are written walk-throughs. We can run any of them live on your own use case.

Add a field without rebuilding the backend

A customer asks for a cost centre on every order.

  1. Open the order entity in TAF Studio and add a field of the type you need.
  2. Add the field to the order screen in the screen designer. Screens are rendered from configuration, so no front-end release is needed.
  3. Add a conditional layout rule if the field should appear or be required only in some cases.
  4. Try it in Development, compare Development with QA, and promote the change as a reviewed release.
Configured

The field, its place on the screen and its layout rule, with no back-end code.

Still yours

A check that depends on other data is a C# rule. Existing records and their migration are yours to assess.

Data and screens

Change an approval flow

Orders above 10,000 now need finance approval as well as the manager.

  1. Open the order’s lifecycle and add the approval step after the manager’s.
  2. Choose who approves: a role, team, manager, record field or saved query. Route by amount band.
  3. Set a reminder and an escalation for steps that sit too long.
  4. Test the new path in QA with a record above and below the threshold, then release it.
Configured

The step, its approvers, the amount-band routing, the reminder and the escalation.

Still yours

A rule the routing options cannot express is a C# rule. “Request more information” from an approver is on the roadmap.

Workflows and approvals

Configure one application for different customers

A small customer wants one approval level and a large one wants three, on the same record.

  1. Each customer is a tenant that uses the same application model, with its own users, roles and records.
  2. Give each tenant the extra fields it needs. Customers add fields to a live app with no database change.
  3. Set each tenant’s approval chain for the same record type.
  4. Each customer sets its own security policy, such as MFA, lockout and session lifetime.
Configured

Customer fields, approval chains and security policy on one shared product.

Still yours

Rules that make your product different stay in C#. Tenant branding and per-tenant limits are on the roadmap.

Build a SaaS product

Inspect a change before releasing it

A change works in Development. What else moved?

  1. Compare Development with QA to see every configuration and reference-data difference.
  2. Choose the changes to include. Reference data is applied in dependency order and migration scripts are carried along.
  3. Build and deploy the release from Studio to QA, then check it there.
  4. Promote to production as a separate, deliberate step.
Configured

The comparison, the selection and the release itself.

Still yours

Deciding to go to production. Release rollback is on the roadmap, so plan a forward fix.

Review and promote changes

Let AI propose a change, then inspect it

You want a new approval screen and would like a first version quickly.

  1. Describe the change to TAFI in TAF Studio.
  2. TAFI proposes a plan and a preview. Nothing is saved yet.
  3. Confirm, and the change is applied under your name, as ordinary configuration on the same model.
  4. Open it in its designer, adjust it, and release it like any other change.
Configured

A first version of the entities, screens or lifecycle you described.

Still yours

Confirmation controls when a change is written. It does not guarantee the plan is complete, so review it like any change.

TAFI

Frequently Asked Questions

Is there a recording of these?

Not yet. These are written walk-throughs, and we can run any of them live on a call using your own use case.

Do I need a developer for these changes?

Configuration changes are made in TAF Studio or the web designers. A rule that goes beyond configuration is written in C# or TypeScript by a developer.

Do these changes reach production automatically?

No. Changes are made in Development and checked in QA. Promotion to production is a separate, deliberate step.

See TechAppForce on your own use case

Pick the change your team makes most often and we will walk through it on your own use case.

Start free trialContact us