Platform · Extensibility
No dead ends.
Every platform is fast until a requirement doesn’t fit, and the workaround built around it becomes the next legacy system. With Plant an App, even the most specific requirement fits inside the application: with a few lines of code, a service you already run, or a new building block.
Stall
Where platforms stop, workarounds start.
A platform is bought to move fast. Then a requirement arrives that it can’t handle, and the team does what it must to deliver.
- 1
A requirement doesn’t fit.
A vendor’s library, a rule no setting covers, a system with a protocol of its own.
- 2
A workaround grows outside.
A script on a server, a spreadsheet in the middle, a small application on the side.
- 3
No one owns it.
It sits outside the application’s permissions and history, and often only one person knows how it works.
- 4
It becomes the next legacy system.
A few years later, it’s in the scope of the next modernization RFP.
The answer isn’t fewer requirements.It’s room for them inside.
Fit
Three ways in, lightest first.
The data model, the forms, the screens, and 450+ ready-made actions cover most of an application. For what’s left, choose the lightest way in that does the job.
- Layer 1
A few lines of code.
C#, JavaScript, or SQL inside a workflow step, a token, or a screen.
For exampleA query, a calculation, a field that reacts as someone types. - Layer 2
A service you already run.
Programs on the server or API services in any language, called from any workflow.
For exampleAn API, an existing Python model, a legacy command-line tool. - Layer 3
A shared building block.
The logic that matters, published once as an approved action that every builder and system uses.
For exampleUpdating a vendor, or an SAP purchase requisition.
Layer 1 · Script
Small gaps stay small.
A calculation no setting covers, a query across tables, a field that reacts as someone types. The code lives inside the workflow, the token, or the screen that needs it. No separate project to build, no library to install.
Workflow stepRun SQL query
SELECT COUNT(*)
FROM Permits
WHERE ParcelId = @ParcelId
AND Status = 'Open'- Parameter
- @ParcelId ← Parcel ID from the application
- Returns
- Open permits
In a workflow step.
Run C#, JavaScript, or SQL as a step, and C# with your own libraries when you need them. Every value in the workflow is available to the code, and what it returns is ready for the next step.
In a token.
Build your own tokens from a SQL query or a C# script, cache them, and use them in any form, email, or document.
On the screen.
Scripts on fields and buttons, listing views from your own HTML and CSS, and a JavaScript API to open forms and refresh listings.
Code is written in an editor inside the builder, with an AI assistant that drafts SQL from plain words. Values reach SQL as parameters, so what someone typed never becomes part of the query.
Layer 2 · Reach
Logic that already runs elsewhere stays there.
The model your analysts built, the engine your team already trusts, the utility that lives on one server. The workflow calls each one where it is, and nothing is rewritten.
Your own services.
Logic written in Python, Java, or any other language is published as an API and called like any other system.
Programs on the server.
Run a command-line program or a PowerShell script (a converter, a legacy tool, an import utility) and use what it returns in the next step.
Calls from outside.
Other systems call the APIs you publish, and the work starts inside the platform.
Layer 3 · Standardize
Write it once. Make it the way everyone works.
Scripts close gaps one at a time. But when every builder writes their own SQL to update a vendor, the workarounds are back, this time inside the platform. So the logic that matters is published once, as an approved action, and every form, workflow, API, and builder works through it.
Built as a workflow.
Every saved workflow becomes an action of its own, with typed inputs, so most approved actions need no C# at all.
Used without the code.
Builders pick the action in the designer and fill in its settings. The rules inside stay the same, whoever uses it.
Changed in one place.
When a rule changes, it changes once, and every form, workflow, and API that uses the action follows.
C#CreateRequisition.cs
public class CreateRequisition : IAction
{
public CreateRequisition(ISapClient sap) { … }
[ActionParameter(IsRequired = true)]
public string CostCenter { get; set; }
public IActionResult Execute(ActionContext context)
{
// Create the requisition through your SAP client
}
}JSONCreateRequisition.json
{
"Title": "Create purchase requisition",
"Settings": { "Group": "SAP" },
"Parameters": [
{ "Id": "CostCenter", "Type": "Select" }
]
}And when an action needs C#.
For the rare operation scripting can’t reach, like a vendor’s .NET library or a protocol of its own, developers implement one of the platform’s interfaces and describe it in a JSON file. Its settings become a form in the designer, and the services it needs are injected.
25+extension points across workflows, listings, forms, validation, search, APIs, and events.
Developers build the pieces.Everyone builds with them.
Keep
Code that doesn’t become legacy.
Workarounds become legacy because they live outside: on a server no one checks, in a script only one person understands. Code written in the platform lives inside the application: it’s in the designer for anyone to see, saved with every version, and still there when its author moves on.
No dead ends.And no new legacy.
Scripting is a capability you choose to enable, so code runs only where you’ve decided it belongs.
Related capabilities
Bring the requirement that broke your last platform.We’ll show you where it fits.
Talk to us about the rule, the system, or the screen your last platform couldn’t handle, and see which way in it takes, from a few lines to a new building block.