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. |
| Unit tests | Write (tests only) | Write or extend ABAP Unit tests. |
| 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.
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.
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.