Build your first app on Createrun.

1. From install to Editor in 30 minutes

Install and start an instance with the Createrun Setup installer, sign in to the browser-basedEditor(Developer Suite) with your IDM account, and create a workspace bound to your instance. Every artefact you design — forms, workflows, queries, BPM flows — compiles into strongly-typed assemblies on save.

You build apps from four primitives:

2. Your first app — a contact form

1. Create a solution and module.In the Editor,New → Solution, name itHelloContacts. Add a moduleContacts.
2. Create a form.New → Form→ContactForm. Add a requiredNametext field, anEmailfield withemailvalidation, and aSubmitbutton part.
3. Bind the form to storage.Open the form's data binding panel and bind a table or stored procedure. The framework generates the typed model and persistence calls.
4. Wire the submit action.Set the button action toInsert, or call a workflow (§4).
5. Compile.Save the form; the Compiler pipeline produces the app assemblies. Failures surface as Roslyn diagnostics mapped toCOMPILER_SYNTAX/COMPILER_SEMANTIC.
6. Run it.Deploy to your instance and open it through CRPortal / the virtual site gate.

Editor gesture tip: removing a field = select it + ribbonSelected → Remove(notRemove Completely, which deletes the whole form).

3. Queries and workflows

Aqueryis parameterised SQL:New → Query→ContactsByEmail, bodySELECT Name, Email FROM Contacts WHERE Email = @email, declare the@emailparameter, then bind the result to a grid or call it from a workflow. Queries compile with the rest of the app — a bad query fails at build time, not at runtime.

Aworkflowautomates server-side logic: add condition nodes and parallel tasks (audit row + notification), then bind the workflow to the form'sSubmitaction. Workflows can be promoted to BPM flows for long-running, human-in-the-loop processes.

4. Publishing to the Store

1. In the Editor, choosePublish to Store. The platform collects your sources and manifest, generates a checksum map, and streams a signed.crpckpackage (ECDSA P-256) to the Store API.
2. The Store validates your IDM JWT, stores the package, re-signs the manifest, and sets the version status tosubmitted.
3. A Store admin reviews the submission; on approval the status movessubmitted → approved → publishedand you receive an email.
4. Customers install your published app from the CRPortal Marketplace; the install pipeline verifies the license JWT and the package signature.

Common publish failures map to documented codes —STORE_VERSION_CONFLICT(bump the version),STORE_CHECKSUM_MISMATCH(rebuild the package),STORE_SIGNATURE_INVALID(signing key mismatch). See theerror-code reference. Failed installs keep a step-by-step trace your Store admin can inspect, and you can file a ticket from/Supportwith the trace id.

5. The gate HTTP contract

Apps expose actions asgate methodsover HTTP. The runtime routes a request to a gate method by name.

• URL shape:/gate/{app}/gatemethods.{group}.{method}(lowercase), e.g./gate/crportal/gatemethods.integration.installapp.
• Envelope:JSON with PascalCase fields, wrapped in the standardResponse<T>envelope carrying acode, an optionaldatapayload, and anerrors[]array on failure.
• Encoding:UTF-8; the API is tolerant of common encoding quirks.
• Auth:instance/developer JWT Bearer (IDM OIDC). Anonymous gate methods are the exception, not the rule.
• Error mapping:every non-success response carries a registrycode— resolve it viaGET /api/v1/error-codes/{code}or thereference page.

6. Getting help

Error codes:reference pageorGET /api/v1/error-codes(public, no auth). Support: file a ticket at/Supportand attach the install trace id when reporting a failed install. Developer tooling overview:Developer Hub.