Overview

Key points

• Studio is its own branded desktop app built on the same engine as VS Code, with the TechAppForce designers built in.
• You sign in with your TechAppForce username and password. Tenant, app and environment come from your sign-in; there are no ids or tokens to paste.
• Everything you see is your own app, read live from the platform. There is no demo or mock mode.
• Edits save to a local working copy first. Nothing reaches the platform until you publish it.

What Studio is

TAF Studio is where developers design and maintain TechAppForce apps: the objects that hold data, the screens people use, the rules that move work along and the reports that come out. Instead of editing raw configuration, you open a visual designer for each part of an app. The TechAppForce features are part of the workbench itself, so the gestures are the ones VS Code users already know: a tree on the left, the Command Palette, the Problems panel, side-by-side diffs.

To use Studio you need a TechAppForce account and an app you administer. You do not need the platform's source code or any other developer tools.

What you can build

• Objects. The tables that hold your data: fields, types, keys and relationships, field settings and validation, lookups to other objects, and the screens that add, edit and list records. You can also register a table that already exists in the database.
• Queries. Saved queries that read and filter an object's rows for screens and reports, including fields of related objects. Run a query to see real rows.
• Screens. Forms and lists built in a drag-and-drop designer that uses the same form engine as the web app, so the preview matches what users see.
• Lifecycles. The statuses a record moves through, the transitions between them, and which screen and workflow each transition uses. The lifecycle is editable as a diagram.
• Workflows and triggers. Automated steps that run on a record event or on a schedule.
• Notifications, reports, menus and permissions. A designer or editor for each, plus app administration: roles, object permissions, users and teams, choice lists, approvals, SLAs and layout rules.
• Scripts. Custom scripts open as real code files with language services. C# scripts can be compile-checked on the platform before you publish. See Scripts and debugging.
• Releases. Create a release, choose what it contains, and deploy it from Development to QA. See Releases in Studio.

Wherever a designer names a related item, such as an object, query or screen, the name is a link to that item. A lookup field opens the object it points at, and an object's children list opens the objects that point back.

How Studio works with the platform

When you sign in and choose an app, Studio pulls the app into a working folder you pick (it keeps everything in a .taf sub-folder and writes nothing else there). You edit that local copy in the designers. When an item is ready, you publish it, and Studio writes it back to the platform through the platform's own routes.

• Nothing is published until you say so, so you can browse and edit freely.
• Every save is also kept in a local history, so you can restore an earlier version of an item without touching the platform.
• Before you publish, TAF: Check for problems scans screens and queries and lists what it finds in the Problems panel: duplicate component keys, fields a query uses that its object does not have, and filter logic the platform would ignore or reject.
• Publishing to an item your app owns is allowed. Publishing to an item inherited from a shared template is blocked, with an explanation, so you cannot change shared configuration by accident.
• To pick up changes made elsewhere, such as in the web app or by a colleague, run TAF: Load latest from platform. If your copy differs, you choose whether to take the platform's version, keep yours, or compare them side by side.

Standard and custom-frontend apps

A standard app uses TechAppForce screens designed in Studio. A custom-frontend app has its own UI code, for example an Angular or React app built on the client SDKs, while the platform still provides data, sign-in, roles, menus and workflows behind it. For a custom-frontend app, Studio can link to the frontend code folder, open it, show its git history, and install, build, run and preview it. Studio does not deploy that code; use your project's own pipeline.

Current limits

Studio tells you when something is not available rather than guessing. Today:

• Releases go from Development to QA. Studio never deploys to Production.
• You can design and preview a database view, and draft a stored procedure against your real columns, but creating them is left to your database administrator.
• Report preview renders the published version of a report, so publish before you preview.
• Scripts that already exist on the platform can be edited and published from Studio. A new script is created outside Studio first, then loaded.
• You can edit layout rules, but new layouts are created in the web app.

Where to go next

• Install and sign in: get Studio running and open your app.
• Explorer and designers: find your way around and build a feature end to end.
• Scripts and debugging: check, run and debug custom scripts.
• Releases in Studio: move a set of changes to QA.