No-Code Customization for NDT ERP: What the no-code customization tools Actually Lets You Build

What the no-code customization tools Actually Is

the no-code customization tools is the no-code and low-code customization layer available in Atlantis ERP, sitting on top of any standard or custom module. It is not a separate product bolted onto Atlantis ERP. It is a visual editor that generates the same underlying model definitions, views, and automation records a developer would otherwise write by hand in Python and XML. For an NDT company running its ERP on Atlantis ERP, that distinction matters: what Studio builds is a first-class part of the database, not a fragile workaround, which means an operations manager without a programming background can make real structural changes to how the system tracks equipment, jobs, and personnel, and those changes hold up the same way a developer-built feature would.

What Studio is not: a general-purpose scripting environment. It has no code editor for writing arbitrary Python business logic, no direct way to call external REST APIs, and no interface for touching database-level constraints or complex multi-table transactions. Understanding that boundary up front is the difference between using Studio productively and burning a week trying to force it to do something it was never built to do.

Custom Fields: The Most Common and Most Useful Studio Change

The single highest-value thing an NDT operations manager typically builds in Studio is a custom field on an existing model. Atlantis ERP's Maintenance and Equipment models track assets generically. An NDT company needs fields specific to inspection equipment that don't exist out of the box:

• A "Next Hydro Test Due" date field on a pressure vessel or gas cylinder equipment record.
• A "Source Activity / Last Leak Test Date" field on radiographic source records, tied to the periodic leak-test interval required for sealed sources.
• A "Certificate Number" and "Calibration Standard Used" field on a UT flaw detector or thickness gauge record, referencing the applicable calibration procedure.
• A "Method Qualification Expiry" field on technician records, separate from general certification expiry, to track method-specific requalification under the employer's written practice.

Adding any of these in Studio takes minutes: drag a Date, Char, or Many2one field onto the form view, set required or optional and default values, and it is immediately available across list views, filters, and reporting. This is genuinely no-code work, no XML, no restart, no developer ticket.

Custom Views: Building the Screens Your Team Actually Uses

Beyond fields, Studio lets you build and rearrange list, form, and kanban views without touching XML. A branch manager who wants a kanban board of open jobs grouped by inspection method, color-coded by days-to-deadline, can build that directly in Studio: add the grouping, add the status colors, add the fields that show on the card face such as client name, method, technician assigned, and due date. The same applies to a simplified data-entry form for field technicians logging equipment checkouts, stripped down to only the handful of fields they actually need to fill in, hiding the rest of the fields on the full equipment record that are irrelevant to a checkout transaction.

This view-building capability is where Studio earns its keep operationally. Most of the "the software doesn't work the way we work" complaints in an ERP rollout come from generic views showing fields nobody needs and hiding the ones people check constantly, and that is a fixable problem without a developer.

The same view-building tools extend to saved filters and simple dashboard elements, such as count widgets and basic pivot views, without any code. A branch manager who wants a saved filter showing all jobs in their region with an assigned technician whose certification expires within sixty days can build that filter once in Studio and pin it as a default view. Multi-branch companies commonly build a small set of these: overdue-calibration equipment by branch, jobs missing a Level III sign-off, technician utilization by method. None of this requires a developer, and it is often the highest-leverage use of Studio because it turns data that already exists in the system into something a manager actually looks at daily rather than something buried in a report nobody opens.

Automated Actions and Scheduled Actions: Where Studio Starts Doing Real Work

Studio's automation layer covers two related but different mechanisms, and knowing which one to use matters:

• Automated actions trigger on a record event: a field changing, a record being created, or a record matching a condition on write. Example: when a technician record's certification expiry date is updated, automatically reset a "Requalification Reminder Sent" flag so the reminder cycle starts over.
• Scheduled actions run on a time-based cron schedule regardless of whether any record changed. Example: a daily scheduled action that scans all technician records, checks whether certification expiry is exactly sixty days out, and if so, sends an automated email to the technician and their QA manager, while separately flagging any equipment record where the calibration due date has already passed.

Both are configurable in Studio's automation builder through a condition-and-action interface: pick the trigger model, set the filter domain, and choose the action, such as sending an email template, creating an activity, or updating a field. This is genuinely powerful, and it is the layer that turns an ERP from a passive record store into something that proactively surfaces problems. An equipment record past its calibration due date should not require someone to remember to check a report; it should flag itself and notify the branch manager automatically.

The limit here is condition complexity. Studio's automation rules handle single-condition or simple multi-condition triggers well. The moment the logic needs to reference data across several related models with conditional branching, for example flagging a job only if the assigned technician's certification expires before the job's scheduled completion date and the equipment hasn't been calibrated within a set window and the job is a code job requiring a specific inspection standard, that is generally past what the no-code condition builder can express cleanly, and it is a sign to bring in someone who can write the underlying Python.

Approval Workflows: Sign-Off Chains Without Custom Code

A recurring need in NDT operations is a multi-step sign-off before a report goes out the door, most visibly for radiographic film or digital image interpretation, where a Level II's interpretation and disposition need a Level III review before the report is released to the client. Studio supports building approval-style workflows using status fields, automated actions, and access rules together: a report record moves through states such as Draft, Level II Reviewed, Level III Approved, and Released, each state transition restricted to users with the appropriate role, with an automated action that notifies the Level III reviewer when a report enters the pending-review state.

This kind of workflow is exactly the sort of process an ASNT Level III consultant setting up a written practice and internal procedure structure would want reflected in the software: the sign-off chain in the ERP should mirror the sign-off chain in the written practice, not exist as a separate manual checklist someone tracks in a spreadsheet next to the actual reports.

Where this gets harder in pure Studio: enforcing that a specific named reviewer, not just anyone holding the Level III role, is the one who approved a specific report, or building conditional routing where different job types require different reviewer chains, starts to need custom access-rule logic and possibly server-side validation that goes beyond what Studio's visual workflow builder handles cleanly.

PDF and QWeb Report Templates: Cosmetic and Structural Changes

Atlantis ERP generates PDF documents, invoices, job reports, and certificates through QWeb templates, and Studio provides a report editor for adjusting these without hand-editing the underlying XML. Adding a company logo, adjusting layout, adding a custom field such as that "Calibration Standard Used" field onto a printed certificate, or reordering sections on an inspection report template are all achievable through Studio's report designer. This matters for a company producing NDT reporting software output as a client-facing deliverable: the printed report is often the only artifact a client actually reads, and getting its layout and content right without waiting on a developer for every tweak is a real operational win.

Complex conditional formatting inside a report template, such as showing a section only when the inspection method is TOFD and the result is a rejectable indication, with a completely different table layout than a UT report, starts to strain the visual editor and often needs direct QWeb or XML editing.

A Worked Example: Building a Calibration-Due Alert End to End

It is worth walking through a single realistic build in Studio from start to finish, because the pieces described above rarely get used in isolation. Consider an operations manager who wants the ERP to automatically warn a branch manager when a UT flaw detector's calibration is about to lapse.

Step one is the field: open the Equipment model in Studio and add a "Calibration Due Date" date field, plus a "Calibration Standard" text field referencing the procedure used, for example a manufacturer-specified interval verified against a NIST-traceable reference. Step two is the view: add that field to the equipment list view and form view, and add a filter so a branch manager can see, at a glance, every instrument in their region sorted by days remaining before due date. Step three is the scheduled action: build a daily cron job in Studio's automation builder that scans all equipment records, checks whether the calibration due date is today plus thirty days, and if so, creates an activity assigned to the branch manager and sends an email using a template that pulls in the instrument's serial number and last calibration date. Step four is the escalation: a second scheduled action checks for equipment where the due date has already passed and changes a "Calibration Status" selection field to "Overdue," which in turn changes the kanban card color on the branch manager's equipment board from green to red because the view is already configured to color by that field.

Every step in that build is achievable entirely inside Studio by someone who has never opened a Python file. The moment this same workflow needs to also check whether the overdue instrument has any jobs scheduled in the next two weeks and automatically flag those specific jobs as at-risk, cross-referencing the Equipment model against the Project or Field Service model with a conditional join, it crosses into logic that Studio's single-model automation builder was not designed to express, and that is the point where a developer writes a small server action instead of fighting the no-code builder into doing something it was not built for.

This worked example also illustrates why Studio-built automations still deserve a second look before go-live, not because Studio is unreliable, but because a scheduled action with a subtle date-logic error, comparing calendar days instead of business days, for instance, or failing to account for a technician's timezone in a multi-region rollout, will run silently and wrong for months before anyone notices the alerts stopped meaning anything. A quick review from someone who has built these before, whether an internal admin or an outside implementation resource, catches that class of error before it becomes a pattern of missed calibration deadlines.

Where Studio Genuinely Hits Its Ceiling

Being clear-eyed about Studio's limits saves an operations manager from a frustrating week trying to force a no-code tool to do something it was not built for:

• Complex business logic. Anything requiring branching conditional logic across multiple models, loops, or calculations beyond basic field arithmetic needs actual Python code in a custom module.
• Third-party instrument API integrations. Pulling calibration data automatically from a flaw detector's proprietary software, or syncing readings from a digital radiography system's DICONDE output, requires a developer building an integration layer. Studio has no mechanism for calling external hardware or software APIs.
• Performance-sensitive customizations. Automations that need to process large volumes of records efficiently, or reports that aggregate across tens of thousands of job records, often need optimized server-side code rather than Studio's general-purpose automation engine, which is not built for heavy computational load.
• Security and access-rule edge cases. Studio handles basic role-based visibility well, but row-level security scenarios, such as a technician seeing their own certification record but not another technician's except through their direct manager or aggregate reporting, frequently need record rules and domain expressions written directly in XML rather than the simplified access UI.

A Decision Framework: What to Build Yourself vs. When to Call a Developer

A practical rule an NDT operations manager can apply before opening Studio:

• Build it yourself in Studio if the change is a field, a view layout, a single-condition automation, a report cosmetic tweak, or a saved filter or dashboard. These are low-risk, reversible, and don't touch core data integrity.
• Bring in a developer or an implementation partner if the change involves logic spanning multiple related models with conditional branching, any integration with outside hardware or software, performance optimization on large datasets, or access-rule design where getting it wrong could expose sensitive personnel or client data to the wrong role.
• Get a second review even for Studio-built changes that touch approval workflows or certification tracking, since a sign-off chain that looks right in testing but has a gap, such as a state transition that skips a required role check, is the kind of thing worth catching before it's relied on for something like an RT interpretation release.

Studio genuinely extends how far an NDT company can customize its own ERP without a development budget for every small change, and for a lean operations team, that is real leverage. The judgment call is knowing where "safe to build myself" ends and "needs a developer" begins, and getting that call wrong in either direction, overbuilding fragile Studio automations for complex logic, or paying developer rates for a change that was a five-minute Studio field addition, is where companies lose the efficiency Studio is supposed to provide.

Atlantis NDT Products & Services

Atlantis NDT pairs field expertise with software: NDT inspection management software — Atlantis ERP, a digital twin platform for asset integrity, and NDT reporting software. Build your team with NDT training & certification (ASNT SNT-TC-1A) and ASNT certification pathways, or bring in ASNT Level III consulting. Affordable, accessible, fully customizable — book a free consultation.