No-code does not mean limited.

All of MitosOne is built on metadata: record types, fields, views, rules, workflows and permissions live in the database. That is why everything specific to your company is defined in the browser — and, when needed, opened up to code through the API.

Data model Views and reports Automation Security Integration Governance Mobile and portal Setup assistant

Data model

Whatever exists in your business exists in the system.

When you create a record type, MitosOne creates a real table behind it — not a so-called “custom field” bag. Relations, sub-tables, file attachments, uniqueness and format checks work both in the browser and at database level.

19 field types: text, long text, integer, decimal, yes/no, date, date-time, e-mail, phone, URL, option list, file, sequence number, user, encrypted field, rollup, lookup and more.
Calculated fields: rollup (sub-table total) and lookup (pulling a value through a relation), nested up to three levels.
A formula language with 43 functions: logic, text, date, maths and aggregation; WORKDAYS uses the public holiday calendar. The same formula gives the same result in the browser and on the server.
Multilingual labels: field names are defined in Turkish, English and German.

studio / fieldsSample Request

talep_no: text · unique · automatic
cari: relation → Accounts
kalemler: sub-table · 1–50 rows
toplam_adet: SUM(kalemler.adet)rollup · recalculated on every record
musteri_segment: LOOKUP(cari.segment)pulled through the relation, permissions included
termin: WORKDAY(talep_tarihi, 5)uses the public holiday calendar
ek_dosya: file · pdf, dwg · max 20 MB

Views and reports

The same data, shaped to each person’s job.

Sales wants kanban, accounting wants a list, management wants a dashboard. In MitosOne a record type can have as many views as you like; each view has its own filter, sorting and column layout.

11 view types: list, form, detail, kanban, calendar, gallery, timeline, pivot, chart, dashboard and process diagram; plus a page and record page designer. Long forms are split into tabs.
Process diagram: on a P&ID-style diagram, symbols are linked to records; values refresh as records are written, an alarm record is opened when a limit is exceeded and a notification goes out through a workflow. It can be embedded in dashboards, record pages and PDF documents. No commands are sent to devices.
30 chart types, with a validated 8-colour palette; dashboards are arranged by drag and drop, and tiles filter one another.
Reports respect permissions: the same report runs with the rows and fields the person opening it is allowed to see.
Analysis: build reports with an Excel-like pivot by dragging rows, columns and measures.
Forecast: on line and area charts, a forecast from the historical series is shown as a dashed line with a confidence band.
Scheduled delivery: a report goes out at the set time as both Excel and PDF; if the result is empty, it is not sent.

Analysis / Sales Dashboard This quarterLive

Measure: net revenue Breakdown: month Source: Sales Order

Automation and process

Two engines: one does the work, the other governs the process.

The workflow engine runs what should happen when something occurs. Stages, in turn, define which status a record can move to from which, by whom and under which condition. Together they cover corporate processes end to end.

Workflow engine

26 nodes, visual canvas

You start from a trigger and connect nodes. Retry on failure, run history and a step-by-step log come built into the engine.

record eventscheduleddatemanualstage conditionmulti-branchloopwaitvariableend update this recordmove stagecreate recordupdate recordquery request approvalin-app notificatione-mailgenerate documentHTTP callscript

Stages

Process rules, without exception

For each transition you define the role, the condition, the fields required at that stage, a list of reasons and whether a comment is mandatory. Segregation of duties (four-eyes principle) prevents the person who created a record from approving it themselves.

// purchase request → order
gecis: Request → Pending approval
  rol: departman_yoneticisi
  zorunlu: [butce_kodu, gerekce]
gecis: Pending approval → Rejected
  gerekce_listesi: [no budget, price too high, cancelled]
  yorum: required

Cross-record condition

Check the status of another record

Rules such as “if the account’s risk limit is exceeded, the order should not go to approval” are written against the related record.

History

Every stage is recorded

How long a record waited at each stage, who moved it on, the reason it was sent back — all tracked on a dashboard.

Notifications

The right person, through the right channel

In-app notifications, e-mail and webhooks; reminders tied to stage changes or to time.

Security and authorisation

Permissions live in the data itself, not on the screen.

Hiding a menu is not security. In MitosOne, row and field rules go into the query itself; they give the same result through every path, including the API, reports, exports and mobile.

Row-level security: rules are translated into parameterised SQL. If a rule cannot be translated, access does not open — it closes.
Field-level security: fields given a confidentiality class are never sent to unauthorised users.
Record scope: for each role, their own records, their department’s or all of them; scope can be narrowed by stage. With “Try as this person” you can see in advance what a user will see.
Roles and delegation: permissions are grouped into roles; permissions can be delegated for a limited time.
Audit log: who changed which value to what, and when — viewable on screen; critical operations are also kept in a separate, append-only log.
KVKK (Turkish personal data protection law): personal data export and erasure requests, explicit consent records, role-based field masking.
Encrypted fields: fields such as Turkish ID numbers (TCKN), IBANs and passport numbers are stored encrypted per field in the database and shown masked; an authorised role reveals them with the eye icon and a stated reason, the value is hidden again after one minute, and every reveal is written to the record history.
Encrypted vault and keys: connection passwords, API keys and integration secrets are encrypted with AES-256-GCM; each company has its own data key, and the master key can, if you wish, live in your own HashiCorp Vault.
Sign-in and access: two-step verification (TOTP), single-use backup codes and 30-day trusted devices; role-bound API keys, and records that can be marked as undeletable.

role / regional manager3 rules

# which orders they can see
bolge == user.bolge

# which accounts they can touch
temsilci_id in user.ekip

# cannot see the cost field
birim_maliyet: gizli

These three lines apply at once in the list, the dashboard, the pivot, on mobile, in the Excel export and in the API response.

Integration

Not a black box. It connects in every direction.

REST API and OpenAPI

Every record type gets an endpoint automatically. An OpenAPI definition specific to your tenant is generated; API keys are limited by role, scope and row rules.

Two-way webhooks

Outgoing: event notifications are signed, failed deliveries are retried and delivery history is kept. Incoming: systems such as Azure DevOps, GitHub and Jira write to your record type the moment an event happens; every request is verified with a secret or an HMAC signature, and only the fields you have mapped are written.

Incoming e-invoices

UBL-TR e-invoice (e-Fatura) and e-archive (e-Arşiv) files (XML or ZIP) are imported, parsed and turned into purchasing records with their line items.

Import and export

Excel (xlsx) or CSV files are imported with a preview; records whose key field matches are updated, and the import can be undone. The “App from Excel” wizard builds the record type, screen and menu from a file in one go. Export to CSV and Excel.

Data sources

No-code connections to REST and SOAP services; credentials are kept in the encrypted vault. For the rare step that really needs code, a time- and resource-limited script node in the workflow.

Real time

When a record changes, screens update instantly; notifications and dashboard figures refresh without waiting.

Governance

Making changes should be easy; so should undoing them.

The well-known risk of no-code systems is that anyone can change anything. MitosOne versions its configuration: what changed, who changed it, what happens if you roll back — all visible in advance.

Versioning: every release is a version; versions are compared on a semantic diff screen.
Planned rollback: a rollback is shown together with its impact before it is applied.
Test environment: a test copy of your company opens with one click; personal and encrypted fields are masked in sample data taken from production.
Promotion to production: roles, screens, processes and document templates built in test move to production at a scheduled time with four-eyes approval; items changed on both sides are shown as conflicts in advance, and a promotion can be rolled back within 30 days.
Recycle bin: deleted records can be restored; data from a removed module is kept for 30 days.
Packaging: the solution you build is exported as a signed module package and installed in another company.
Multilingual: the interface, server messages and your own metadata labels in tr/en/de.

version / v12 → v13preview

Sales Order	field added · teslim_yeri	Safe
Sales Order	made required · butce_kodu	412 records
Regional Manager	row rule changed	Permission
Quote PDF	template updated	Safe

4 changesRollback plan ready

Mobile and external users

Field staff and customers, in the same system.

Mobile

Every screen you define is on the phone too

The mobile interface is generated from the same metadata; when you add a new record type, no separate mobile development is needed. Barcode record search and push notifications included.

Offline

Records can be entered even without signal

Offline writing, including sub-tables and file attachments; queued records are sent once the connection returns.

Portal

Customer and supplier access

Public forms (with file attachments), portal accounts, access limited to the company’s own scope, captcha-protected submission. A company’s portal administrator invites its own employees.

AI-assisted setup assistant

Describe your work, it proposes a plan, you approve.

Your system administrator describes what they want to build in their own words. The assistant clarifies gaps with questions and produces a step-by-step setup plan; each step is built only once it is approved.

Scope: record types and fields, screens, approval workflows and roles, dashboards, process diagrams, document templates, reports, translations and sample data.
Approval and rollback: each step is approved separately and undone with one click; when the plan changes, the diff of the new version is shown.
Risky steps: steps that change permissions or open the system to the outside (webhooks, data pulls, portal) require separate approval and are set up disabled.
Secrets stay with you: the assistant never asks for passwords or keys; you enter them yourself on their own screen.
No code: everything it builds is identical to what you would build by hand in Studio and can be edited later. Only system administrators use it.

Rather than describing the platform, let us build your process.

Bring one of your processes to the demo. In 45 minutes, on screen, without writing code, we will build it and hand it over to you.

Book a demo See ready-made modules