Extensibility

Code where configuration stops

Most of an app is configuration. The rule unique to your business deserves real code, inside the same app.

Illustrative

OrderCreditCheck.cs


// Illustrative: a validation hook on the Order entity.
// Adding an error stops the save and tells the user why.
public class OrderCreditCheck
{
    public Task Validate(HookContext context)
    {
        var total = Convert.ToDecimal(context.Fields["Total"]);
        var limit = Convert.ToDecimal(context.Fields["CustomerCreditLimit"]);

        if (total > limit)
        {
            context.Errors.Add(
                $"Order total {total:N2} is above the credit limit of {limit:N2}.");
        }

        return Task.CompletedTask;
    }
}

A simplified validation hook: read the record, decide, add an error to stop the save.

The problem

Low-code works until the one rule it cannot express

Then teams bend the process, or build a second system and keep the two in sync.

Typical low-code

Bend the process to fit the tool
Or build a second system next to it
And keep the two in sync forever

TechAppForce

Write the rule as real code, inside the app
Same data and permissions as everything else
Moves with the app’s releases

How we solve it

Five supported places for your code

Pick the one closest to your rule. Each is part of the platform, not a workaround.

Entities and fieldsRecord hooks: validate, before and after saveC#
Workflows and schedulesWorkflow actions: the step no standard one coversC#
Platform APIsYour own versioned endpoints (Virtual URLs)OpenAPI
Screens and formsScreen extensions and your own componentsTypeScript
The standard web appYour own front end on the client SDKsAngularReact

Same data. Same permissions. Same release.

What you get

Real languages, real tools

Open a tile for detail.

C#Compiled and checked
The platform compiles every script and checks it first. A script that uses a disallowed API is rejected, not run.
Debug in TAF Studio
Check a script, debug it and read the runtime logs next to the entity it belongs to.
Released like configuration
Scripts appear in the release diff and move with the screens they support.
v1 · v2Versioned endpoints
Each Virtual URL has its own path and version, so v2 can change without breaking v1 callers.
An OpenAPI spec
Every endpoint is described in a standard spec partners and tools can read.
A generated typed client
A generator turns the spec into a TypeScript client for your front ends.
Angular · ReactClient SDKs
A typed query builder, lifecycle and approvals, and unstyled components such as a grid, form, list and inbox.
Access enforced on the server
Custom endpoints and front ends need a valid sign-in, and the server enforces access on every call.

Worked example

An order with a credit check

One app, one release, one set of rules. Open a step for detail.

Configure the orderDetails
The Order entity, its form and its Draft → Submitted → Approved lifecycle are configuration.
Add a validation hookDetails
A short C# hook stops any order above the customer’s credit limit, like the example at the top.
Add a workflow actionDetails
When a customer is created, a script asks the credit bureau for a limit and saves it.
Publish an API for partnersDetails
A versioned Virtual URL lets a partner submit orders, with an OpenAPI spec to build against.
Build the customer portalDetails
A React portal on the client SDK lets customers submit orders through the same lifecycle and credit rule.
One app, one release

Use cases

Examples you can build

Illustrated apps, each with its records, approvals, screens and reports.

What each example covers

Purchase and expense approvals: Route every purchase request and expense claim to the right approvers, with deadlines.
Leave and HR requests: Leave requests, balances and new-starter onboarding in one place, with manager approval.
Customer onboarding: Take every new customer from signed to live with checks, calls and a welcome.
Field service and work orders: Schedule, dispatch and close out work orders, then bill for them on time.
Admin tools on an existing database: Put screens, roles and change history on tables you already have.
A multi-tenant SaaS product: Sell one product to many customers, and let each one make it their own.

All use cases →

Show us the rule you think no platform can handle

Bring the requirement that broke your last low-code tool. We will show you where it lives on TechAppForce.

Book a demo Client SDK docs