SE43 — Area Menu Maintenance
SE43 (in current systems it routes to SE43N) maintains Area Menus, tree-structured collections of transaction codes, reports, and other nodes that appear as folders in the SAP Easy Access menu. An area menu is a standalone reusable object; it has no security of its own and only becomes visible when set as a user's default menu or inserted into a PFCG role's menu tree.
This page covers the Area Menu maintenance transaction SE43/SE43N: what an area menu actually is, how it differs from a PFCG role menu, and the practical steps to build or change one. The pitfalls section focuses on the recurring incidents: orphaned menus, stale role menu caches after edits, dead transaction nodes, and transport gaps.
Reviewed by an ERPClimb SAP consultant on 15 Sept 2026· 1,232 words
Purpose
SE43 (which in most current systems opens the SE43N editor directly) is the maintenance transaction for Area Menus, hierarchical trees of folders and leaf nodes where each leaf points to a transaction code, a report, or a document/web address. Area menus are what populate the folder structure a user sees under SAP Easy Access, and each SAP module ships with its own default area menu. The structural fact that causes most confusion: an area menu is a standalone object with no user or role attached to it. It only becomes visible to anyone when it is set as a user's default start menu via a user parameter, or when it is inserted as a node inside a PFCG role's menu tree. Editing the area menu itself changes nothing for end users until whatever references it is refreshed.
When it is used
Consultants reach for SE43/SE43N when building a shared, reusable navigation folder that multiple roles need to expose without duplicating the same menu structure inside every role, for example a custom folder grouping the transactions used for a specific daily process. It is also used to inspect or adjust the standard area menus that ship with a module, which appear by default in Easy Access. It sits one layer below PFCG: PFCG builds the role-specific menu and can pull in an area menu as a node, but the area menu is the building block, not the authorization object. It has zero security enforcement of its own; a transaction visible in an area menu is still fully subject to the user's normal authorization check, so an entry showing up does not mean the user can execute it.
How to use it in practice
- Call SE43 or SE43N directly.
- Enter the area menu code; standard ones carry a module-related prefix, custom ones must use the Y or Z namespace.
- Choose Display to inspect or Change to edit.
- In the tree editor, select a folder node and insert a new subfolder, or insert a leaf node for a transaction code, report, or web address.
- Assign short and long texts to each node; reorder nodes with drag operations or the tree editor's move functions.
- Save; a custom (Z/Y) area menu requires assignment to a package and a transport request.
- Verify by inserting the area menu into a PFCG role's menu tab, or setting it as a test user's default start menu, then logging that user off and on.
Key data objects
- TTREE - the menu tree structure table, one row per node, holding the parent-child relationship, node type (folder, transaction, report, document), and the target object key for leaf nodes.
- TTREET - the language-dependent text table for each node, holding the short description shown in the tree.
- PFCG role menu storage - when an area menu is inserted into a role, the role's own menu tables capture that reference at the time of insertion or regeneration; changes made afterward to the source area menu are not automatically reflected there until the role menu is refreshed.
How to prove it in the data
Run SE16 on TTREE filtered by the area menu code to list every child node in creation order, and check the node type and target key field on each leaf to confirm which transaction, report, or document it actually points to. Cross-check texts against TTREET on the same node keys and language. There is no reverse-lookup table listing which roles reference a given area menu; confirming that requires opening each candidate PFCG role's menu tab and checking whether it contains a node of type area menu carrying that code.
ECC vs S/4HANA
The area menu mechanism itself is unchanged on S/4HANA; SE43 typically routes straight into SE43N, and the tree editor behaves the same way it did in ECC. What changed is the front end: Fiori Launchpad, driven by catalogs, groups, and spaces, has largely replaced Easy Access as the primary navigation layer for end users. Area menus remain relevant mainly for GUI-heavy back-office roles, background/batch user menus, or classic navigation inside SAP GUI or NWBC; there is no dedicated Fiori app that replaces the concept because Fiori navigation is built on a different model entirely.
Common pitfalls and how to diagnose them
- Orphaned area menu: the object was built and saved but never assigned anywhere, so nobody sees it. Check whether any PFCG role's menu tab references the code and whether any user's default start menu parameter points to it before assuming the build failed.
- Stale content after edit: a role that references the area menu keeps showing the old folder structure after the area menu was changed, because the role's menu was materialized at insertion time or last regeneration. Editing the area menu again does not fix this; the fix is to reopen the role, refresh or reinsert the area menu node, regenerate the profile, and have the affected users log off and back on.
- Dead leaf node: a node points to a transaction code that was later deleted or locked in SM01, so the user sees the folder entry but gets an error on execution. Check the target transaction's existence and lock status directly rather than assuming the menu build is broken.
- Transport gap: a custom area menu created in a development client is not transported, or the transport lands but the role that embeds it is not included in the same or a coordinated transport, so the target system shows an empty or partial folder. Check the transport request's object list against both the area menu and every role that references it.
- Concurrent edits overwriting each other: two people editing different branches of the same custom area menu without proper transport sequencing can leave node order or texts inconsistent. Check version history through the standard object version tools rather than re-editing blind.
Whose problem this is
Technical build of the area menu (namespace, package, transport) is an ABAP or Basis task. The decision of which transactions belong in it, and which roles should embed it, belongs to the functional or security team designing the role. A good handover states the area menu code, package, transport number, the list of nodes with their target transactions, and every role or user parameter that references it.
Related SAP objects
Reviewed pages this object connects to in the ERPClimb knowledge graph.
Source: ERPClimb — https://erpclimb.com/sap-tcodes/se43ERPClimb is an independent platform and is not affiliated with SAP SE. Reference pages are written and reviewed by SAP consultants for learning and troubleshooting.