Developer roles
The Development product groups the roles that build, review, test, and analyze ABAP. Some write to SAP; several are read-only and physically cannot. You pick a role in the Chat composer; if you are not sure which fits, start with a read-only role like Research.
This page documents every Development role. The build-focused roles (CDS, RAP, Fiori, Migration, Migration Map, Clean-core check) have their own page — see CDS, RAP, Fiori & migration. Adobe Forms has its own page too — see Adobe Forms.
For how roles enforce permissions at the tool level, see How roles work.
At a glance#
| Role | Read/Write | Use it to… |
|---|---|---|
| Development | Write | Implement a requirement end to end. |
| Architecture | Read-only | Get a solution design and plan only. |
| Code review | Read-only | Review objects against your standards, with ATC and unit tests run as evidence. |
| Unit tests | Write (tests only) | Write or extend ABAP Unit tests, and settle a review's open experiments. |
| ATC check | Write | Run ATC and report findings. |
| ATC remediation | Write | Run ATC and fix findings category by category. |
| Research | Read-only | Investigate and answer with evidence. |
| Specification | Read-only (SAP) | Normalize a raw client spec. |
| Effort estimate | Read-only | Turn a spec into an honest effort estimate. |
Development#
Read/Write: Write. The default role.
Development implements a requirement end to end. Its methodology is deliberate: explore the system → reuse first (find and prefer existing objects) → plan the change → lock and set source → validate (syntax + ABAP Unit + ATC) → activate → unlock → report. It never deletes anything, and it makes the smallest change that satisfies the requirement.
When to use it: the main working role — any time you want a change actually built and activated in SAP under your direction.
Development writes to SAP during the conversation you are directing. For a hard human-approve-and-apply gate on every write, use Autonomous mode instead.
Architecture#
Read/Write: Read-only.
Architecture produces a solution design and plan only — the objects to create or change, the patterns to use, the data model, the transport strategy, and the risks. It does not write, lock, or activate anything; it hands you a plan you can review before any code is written (for example, by a follow-up Development run).
When to use it: at the start of a non-trivial requirement, when you want to agree the shape of the solution before building it.
Code review#
Read/Write: Read-only.
Code review reads your target object(s) and reviews them against the project's standards. It returns prioritized findings — Critical / Major / Minor — each with a location and a concrete fix suggestion. It changes nothing. Where the connection allows it, the review does not stop at reading: it runs syntax check, ATC and the object's unit tests and quotes what they returned, so each finding is labelled VERIFIED (a tool produced the evidence) or REASONED (established by reading). It also audits the code's own safety claims — a comment promising never or always must name what enforces it — and, for anything claiming a round trip, states what it can read versus what it can actually write back. On a QA/PROD connection the checks are withheld by the read-only guarantee, and the review says so up front.
When to use it: to check work against your team's conventions, or as an independent review of a change before it moves on.
Unit tests#
Read/Write: Write — test code only.
Unit tests writes or extends ABAP Unit tests for the target. It never changes production logic: if it finds a bug in the code under test, it reports the bug rather than editing the production code. It runs the tests until they are green.
When to use it: to add or grow test coverage on existing code without any risk of altering behaviour.
It is also where a Code review's open questions get settled. A review is read-only: when a finding rests on an assumption a test could prove or disprove, it ends with an EXPERIMENT block — the claim, the test to write, and what each outcome means. Hand that block to Unit tests and it writes the test, runs it, and says which outcome came out, including when the answer is the uncomfortable one. A block that needs a throwaway object or a repository write is refused rather than smuggled into a unit test — that one needs a development role.
ATC check#
Read/Write: Write.
ATC check runs the ABAP Test Cockpit on the target and reports the findings, grouped for readability. It is lightweight: it fixes findings only if you explicitly ask. Its systematic sibling is ATC remediation, below.
When to use it: a quick quality pass to see what ATC flags, without committing to fixing it.
ATC remediation#
Read/Write: Write.
ATC remediation runs ATC and then fixes findings one category at a time — Performance, then Security, then Robustness, then Cleanliness — making behaviour-preserving changes and re-checking after each category. It requires and creates its own dedicated transport and never borrows an existing one.
On a QAS or PROD system it becomes read-only and only reports; remediation writes are for development tiers.
When to use it: a systematic clean-up of an object's ATC findings, when you want the fixes done in disciplined, verifiable passes.
ATC remediation is the write, fix-it sibling of ATC check. Pick ATC check to only report; pick ATC remediation to report and fix, category by category, on its own transport.
Research#
Read/Write: Read-only.
Research investigates and answers questions with evidence — it reads source, structure, and where-used information, and it can run SQL queries for data questions. It changes nothing. It is a good, safe first role when you are exploring an unfamiliar system.
When to use it: any "how does this work / where is this used / what does the data say" question, with zero risk to SAP.
Specification#
Read/Write: Read-only toward SAP.
Specification converts a raw client spec — pasted text, an Excel file, or a .docx — into Makion's normalized internal spec format. It writes only spec files in the workspace (never to SAP), with versioning, and feeds the Specifications tab.
When to use it: to turn a messy incoming requirement into a clean, structured spec that other roles (like Effort estimate or Development) can act on.
Effort estimate#
Read/Write: Read-only.
Effort estimate turns a spec into an honest effort estimate: a per-object complexity band (S / M / L), hour ranges rather than false-precision single numbers, explicit assumptions and unknowns, and an overhead allowance. It produces a downloadable estimate file and writes no code.
When to use it: to scope and price work from a spec, with the uncertainty stated up front.
Related pages#
- How roles work — the permission model behind every role.
- Chat — pick a role and send a task.
- CDS, RAP, Fiori & migration — the build and migration Development roles.
- Adobe Forms — clone and adapt SAP Interactive Forms.
- Specifications — where Specification output lives.
- Methodology — customize the base rules each role follows.
- Autonomous mode — the human-gated apply pipeline for writes.