Permen PU No. 5/2026 BIM workflow in Plannerly

Map Indonesia's new BIM regulation to a working Plannerly setup. Five steps - BEP and EIR documentation, LOIN in Scope, IDS export, IDS import in ArchiCAD, and a simple ISO 19650 CDE in File Manager. Indonesian webinar, English subtitles available.

TL;DR

This article walks you through the BIM workflow demonstrated in Session 2 of Plannerly's free Indonesian webinar series, presented by Harbayu (Plannerly's Indonesian partner). It maps directly to the new Indonesian Ministry of Public Works regulation Permen PU No. 5/2026, and shows how to use Plannerly to handle BEP and EIR documentation, build a Level of Information Need (LOIN) inside Scope, export and import IDS files for open BIM model checking, and run a simple, ISO-19650-aligned Common Data Environment from File Manager. The embedded video is presented in Bahasa Indonesia - English captions and an English audio dub are available inside the YouTube player.

Watch: How Plannerly supports the new Indonesian BIM regulation - Permen PU No. 5/2026 (presented by Harbayu in Bahasa Indonesia).

ⓘ
Good to know - watch in your language
The recording above is in Bahasa Indonesia, but you can watch it in English (or any supported language) without leaving the page. Open the YouTube player settings (the gear icon on the video toolbar), then under Subtitles/CC choose English (or use Auto-translate to pick another language). If an auto-dubbed track is available, you can also switch the spoken voice under Audio track to English. The article body below is written in English regardless of the audio you choose.

What this workflow gives you

Indonesia's Ministry of Public Works (Kementerian PUPR) has released Permen PU No. 5/2026, a regulation that sets out how BIM must be governed when it is used on a project. It does not force every project to use BIM, but if BIM is used, the regulation requires structured documentation (EIR, BEP), a working Common Data Environment, agreed Levels of Information Need, and a traceable model audit trail. This article walks you through the same end-to-end workflow Harbayu demonstrated in the live webinar, using Plannerly as a single, localizable platform that maps to each of those clauses.

In ISO 19650 terms, you will assemble the documents (BEP, EIR), the schedule (MIDP/TIDP), the requirements (LOIN expressed as IDS), the production-side check (importing IDS into your authoring tool), and the file governance (a simple CDE with WIP, Share, Publish, and Archive folders). Each of the five steps below is one part of that picture - work through them in order to leave with a working setup that is defensible against the new regulation and aligned with the wider ISO 19650 family.

This guide covers 5 steps. They follow the order Harbayu used in the demo so you can pause the video at any point and pick up the same screen in Plannerly.

Start Step 1 Free Certified Training Courses
Step 1 - Set up project documentation accountability

Permen PU No. 5/2026 expects every BIM project to have a clear EIR (employer's information requirements) and a BEP (BIM execution plan) that are live, traceable, and tied to named responsible parties. In this step you set those documents up inside Plannerly's Docs module so that every stakeholder is working from the same single source of truth, with comments, status, and version history all in one place.

 Module - Docs & Templates   Output - Live BEP and EIR with assigned team and working hours 

Required checklist

  • Create the project and open the Docs module
  • Spin up a BEP from the template library, then add the EIR alongside it
  • Invite every party who needs to comment, review, or approve - and set their role
  • Record project working hours and the project description so reports inherit them
  • Set the document status (In Progress, Share, Publish) deliberately at each stage

1.1 - Build the BEP and EIR from templates

Open your project and go to the Docs module. Use the template library to create a new BEP, then add the EIR so the two governance documents live side-by-side. Plannerly stores them inside the project rather than scattered across email, Word files, and shared drives - which is the failure mode the new regulation is specifically pushing teams away from.

Each document is a live document. As the project moves on, you keep editing the same record instead of producing another versioned attachment, and every change is tracked.

Why this matters: Permen PU No. 5/2026 treats BEP and EIR as mandatory governance artefacts on any BIM project. Having them inside one platform makes them auditable, comment-able, and impossible to lose - which is what an inspecting party will look for.

1.2 - Add the team and project context

From the document, add every party who needs visibility - appointing party representatives, lead appointed party, BIM coordinators, modellers, and any reviewers. Give each person a role so the document knows who can comment, who can edit, and who can approve.

Then fill in the project basics that downstream documents inherit: project description, scope summary, working hours, holidays, and any local code references. Everything you put in here flows automatically into reports, exports, and the timeline view, so you only enter it once.

Why this matters: Most disputes about BIM deliverables start as disputes about who agreed to what, when, and on which working calendar. Capturing this once at the document level removes that ambiguity for every downstream output.

1.3 - Move documents through In Progress, Share, and Publish

As the BEP and EIR mature, change the document status deliberately:

  • In Progress - the authoring team is still drafting
  • Share - circulated for review and comment
  • Publish - the agreed, baselined version

When you need a follow-up document (for example, a project-specific EIR derived from the master), use the existing record as a database and clone it. You build the next document in seconds rather than starting from a blank page.

Why this matters: Status discipline is what turns a document store into a real governance system. It tells reviewers what they are looking at, and it gives the regulator a clear handover point.
Step 2 - Build the Level of Information Need (LOIN) in Scope

The regulation expects every BIM project to define what information must be delivered, at which milestone, at which Level of Detail (LOD), and against which parameters. In Plannerly's Scope module you build that as a structured table - elements down the side, milestones across the top, with LOD bands and information parameters in each cell. This is your MIDP/TIDP and your LOIN in one view.

 Module - Scope   Output - LOIN with milestones, LOD, and information parameters 

Required checklist

  • Add the regulation's milestones (for example: Pre-planning, Planning, Design, Construction, Operation)
  • Add an element row for every component the model must contain (walls, doors, MEP, etc.)
  • Set the LOD band reached at each milestone for each element
  • Attach the ~26 information parameters required by the regulation to the appropriate LOD band
  • Use AI to generate a visual reference image for each element so reviewers see the intent fast

2.1 - Add the regulation's milestones and elements

Inside Scope, add a milestone for each phase Permen PU No. 5/2026 lists. Harbayu used the regulation's own phase names so an auditor can map the workflow back to the source document line by line.

For each component the project model must contain (walls, doors, slabs, MEP equipment, structural members), add an element row. You can start small with one or two elements while you learn the workflow, then expand to the full element list later. For each element, give it a code that matches your project's naming convention and the IFC entity it maps to (for example, a wall maps to IfcWall).

Why this matters: The regulation's clauses talk about milestones, LOD progression, and required information by element. Mirroring that structure inside Scope means your evidence of compliance is the screen you work on every day, not a separate report.

2.2 - Set the LOD band at each milestone

For each element, fill in the LOD reached at each milestone - for example LOD 100 at Pre-planning, LOD 200 at Planning, LOD 300 at Design, LOD 400 at Construction, LOD 500 at Handover. The regulation defines the expected progression, and Scope makes it explicit so every modeller knows exactly when each level is due.

If you are not sure how to phrase a description, click the AI assist button on the row to draft one, then review and refine it. The goal is short, unambiguous language that a modeller can act on without asking follow-up questions.

Why this matters: LOD progression is the single most common cause of disputes between appointing and appointed parties. Setting it once, in a shared table, removes ambiguity for the whole life of the project.

2.3 - Attach the required information parameters

The regulation lists roughly 26 parameters that have to be carried by elements at the right LOD - object name, classification code, fire rating, acoustic rating, manufacturer, asset code, and so on. In Scope, attach each parameter to the element at the LOD band where it first becomes required. Lower LODs only carry the parameters they need; later LODs inherit the earlier set and add new ones.

Because the parameters live on the LOD, not on the milestone, your modellers can see at a glance which fields they have to populate before a model is fit for that stage. This becomes the source of truth for the IDS file you export in Step 3.

Why this matters: A model without information is, in the regulation's framing, "an expensive empty shell". Attaching parameters at the right LOD is what turns geometry into auditable, asset-grade data.

2.4 - Generate visual references with AI

For each element row, use Plannerly's AI image generation to add a quick visual reference. This is not the model itself - it is a thumbnail that helps non-modellers (owners, regulators, juniors) instantly recognise what is being talked about. It saves long debates in review meetings about whether everyone is picturing the same thing.

Free Plannerly accounts have generation limits, so use this where it adds the most value - typically the most visually ambiguous components.

Why this matters: The faster a stakeholder recognises an element, the faster they sign off on its LOD and parameter set. Visual references shorten the agreement loop.
Step 3 - Export the LOIN as an IDS file

IDS (Information Delivery Specification) is the buildingSMART open standard for expressing information requirements as a machine-readable file. Once your LOIN is structured in Scope, Plannerly can export it as an IDS file that any IDS-aware authoring or checking tool can consume. This is the bridge from "what we agreed in Scope" to "what the model actually has to satisfy".

 Module - Scope   Output - Versioned IDS file shared with named teams 

Required checklist

  • Pick the IFC entities you want the IDS to cover (IfcWall, IfcDoor, etc.)
  • Create the IDS - Plannerly auto-versions it if a same-named file already exists
  • Share the IDS only with the team that needs it (BIM team, modellers, auditors)
  • Download the IDS file ready to import into your authoring tool

3.1 - Create and version the IDS

From Scope, open the IDS export. Give the file a meaningful name (for example IDS_01), pick which IFC entities the file should cover, and click Create. If you already have an IDS with the same name, Plannerly automatically increments the version - so you always know which iteration is current and you never overwrite history.

Versioning matters here: the IDS is the contract between the requirements side (Scope) and the production side (the modeller in their authoring tool). When the requirements change, you re-export and re-version, and every downstream check stays in sync.

Why this matters: A versioned IDS is the smallest possible unit of "what the model must contain". It is the open-BIM equivalent of a signed specification - and because it is machine-readable, a checker can prove compliance instead of arguing about it.

3.2 - Share with role-scoped access

The IDS does not need to be visible to everyone on the project. Share it with just the BIM team or modelling team that needs to consume it - or whichever role group you have set up. This keeps the project tidy and makes sure each stakeholder only sees the requirements they are accountable for.

Why this matters: Role-scoped sharing is what stops the CDE turning into a free-for-all. The regulation expects clear lines of responsibility - sharing each artefact only with its responsible party makes those lines explicit.

3.3 - Download the IDS

Once the IDS is created and shared, download the file. You now have a portable, open-standard requirements file ready to inject into any authoring tool that supports IDS - which is the focus of Step 4.

Why this matters: Because IDS is an open standard maintained by buildingSMART, the same file works across authoring tools. You are not locked in to one vendor, and your requirements travel with the project.
Step 4 - Import the IDS into your authoring tool and inject parameters

The IDS file you exported in Step 3 tells the authoring tool exactly which parameters need to exist on which elements at which LOD. Most modern open-BIM authoring tools - the demo uses ArchiCAD - have an Interoperability menu that imports IDS directly. Once imported, the modeller works through the parameter list and injects the data, then exports the model back as IFC for verification.

 Module - Authoring tool (ArchiCAD example)   Output - Model with regulation-required parameters injected 

Required checklist

  • Open the model in your IDS-aware authoring tool (the demo uses ArchiCAD)
  • Use the Interoperability menu to Import IDS File
  • Open the IDS detail view and confirm every required parameter is listed
  • Inject values into each parameter against the relevant element instances
  • Export the model back as IFC, ready for verification in Plannerly

4.1 - Import the IDS into ArchiCAD (or your preferred tool)

Open the model in ArchiCAD, find the Interoperability menu, and choose Import IDS File. Point it at the IDS you downloaded in Step 3. ArchiCAD reads the file and surfaces every parameter the regulation requires for each element type.

The same principle applies in any IDS-aware authoring tool. IDS is an open buildingSMART specification, so any vendor that calls itself a BIM tool should support it - but always check your version's release notes.

Why this matters: This is the moment the regulation's requirements physically reach the model. Before this, requirements were paperwork. After this, they are data attached to geometry.

4.2 - Inject parameter values against elements

With the IDS imported, work through the parameter list and populate the values for each element instance. Classification codes, fire ratings, manufacturer details, asset codes - whatever the LOD at this milestone demands. The IDS tells the authoring tool which fields to enforce, so any missing value is visible immediately.

If a project uses naming or coding conventions defined upstream (for example, a code such as BGN-WALL-01), the IDS carries those conventions with it. Modellers do not have to invent the codes - they apply the ones already agreed in Scope.

Why this matters: This step is what turns BIM from a 3D model into an information-rich asset. The regulation explicitly requires that drawing extracts and downstream uses (costing, scheduling, operations) all originate from this single, parameter-rich model.

4.3 - Export and prepare for verification

Once the parameters are injected, export the model back out as IFC. That IFC file is what you will run against your IDS in Plannerly's verification workflow to prove the model meets the LOIN you defined in Step 2.

This loop - Scope defines, IDS specifies, authoring tool injects, Plannerly verifies - is the closed-loop quality control system the regulation asks for.

Why this matters: Without the export-and-verify loop, the IDS is just a wish list. Closing the loop is what makes the regulation enforceable and the model defensible.
Step 5 - Run a simple, ISO-19650-aligned CDE from File Manager

Permen PU No. 5/2026 requires a Common Data Environment for any project that uses BIM. You do not need a separate, expensive CDE platform to satisfy that - Plannerly's File Manager already provides the four core CDE states (WIP, Share, Publish, Archive), naming-convention enforcement, filtered views, and team-based access control. For a large share of real projects, that is enough.

 Module - File Manager   Output - WIP / Share / Publish / Archive CDE with naming and access controls 

Required checklist

  • Open File Manager and confirm the WIP, Share, Publish, and Archive folders
  • Configure the project's file naming convention so uploads are auto-renamed
  • Upload models, drawings, and PDFs into the right state
  • Use the Filter to narrow the view by author, state, or file type
  • Create role-based teams (for example a Handover team) and restrict folder access

5.1 - Use the four CDE states

File Manager is built around the four ISO-19650 information states:

  • WIP - work in progress, only visible to the originating team
  • Share - shared for cross-discipline coordination and review
  • Publish - approved and released for use
  • Archive - superseded versions retained for traceability

When you upload a file, decide which state it belongs in. Models open in the in-app viewer for quick review, and PDFs open in place too - so reviewers do not have to download files just to glance at them.

Why this matters: The regulation does not invent a new CDE definition - it leans on ISO 19650's four states. Using the same four states in File Manager keeps you aligned with both regimes at once.

5.2 - Enforce a project naming convention

Set the project's naming convention once in File Manager. From then on, every uploaded file is auto-renamed to match. You can pick a built-in convention or build a custom one to match a client or national standard - which is exactly what local Indonesian projects often need to do under the new regulation.

Auto-naming is the difference between a CDE and "a folder of files everyone names differently". It is also the difference between a fast audit and a slow one.

Why this matters: Most CDE failures are file-name failures. Letting the platform enforce the convention removes the most common source of human error in document control.

5.3 - Filter the view to find anything fast

Use the Filter in File Manager to narrow the view by author, file type, state, or any other field. Filtering by author (for example, all files from the architect) gives you a one-click view of what each party has uploaded - which is exactly the lens an auditor will want.

Why this matters: A CDE is only useful if the right file can be found in seconds. Filtering turns a flat folder of hundreds of files into the slice you actually need.

5.4 - Create teams and restrict folder access

Create teams that match the way your project actually works - for example, a Handover team that owns the Archive folder, or a Coordination team that owns Share. Then restrict each folder so only members of the relevant team can see or change its contents.

This is what stops the CDE from acting like a generic shared drive. Every action is attributable, every folder has an owner, and accidental data leaks become structurally hard rather than only policy-prohibited.

Why this matters: The regulation is explicit that the CDE must support clear lines of accountability and protect data appropriately. Team-based folder permissions make those rules enforceable rather than aspirational.
What you have achieved

Your Permen PU No. 5/2026 setup, end-to-end

By following this workflow you have built a complete, defensible BIM-governance setup that:

  • Documents the project with a live BEP and EIR, assigned team, and recorded working context
  • Defines the LOIN as a structured table of milestones, LOD bands, and ~26 information parameters per element
  • Specifies those requirements as a versioned, role-scoped IDS file
  • Injects the required information into the model in your authoring tool
  • Governs the project's files in a simple, ISO-19650-aligned CDE with WIP, Share, Publish, and Archive states, naming-convention enforcement, and team-based access

Every step maps to a clause in Permen PU No. 5/2026 and to the wider ISO 19650 family. It also leaves you with one connected source of truth instead of the scattered Word, Excel, email, and shared-drive setup the regulation is steering teams away from.

Related resources

Continue learning

Need help while working through this guide? Use the in-app chat for immediate support from Emma (our AI assistant) or a real team member.