This document outlines the planned features and improvements for AtroPIM / AtroCore.
Coming Next
(0 to 3 Months)
Enabling and disabling installed modules without uninstalling them
Currently, turning a module off means removing it completely. This feature lets users deactivate an installed module and re-enable it later, keeping its code and configuration intact.
Adopting the Symfony ExpressionLanguage component
Use the Symfony ExpressionLanguage as an additional (to Twig) consistent engine for evaluating expressions and conditions across the system. It first replaces the current Twig-based condition checks, then extends to matchings, data quality rules, and more – making these features easier to configure and reason about.
Execution preview for consolidation scripts within Master Data Management
See how an entity will look after a consolidation script runs, before applying it. Authors can validate the result up front, making scripts safer to write and commit.
Adopting OAuth 2.0
Replace our custom authentication with a standards-based OAuth 2.0 using league/oauth2-server. The ongoing HTTP pipeline rework (Slim to mezzio-fastroute with PSR-15 handlers) lays the groundwork: a clean PSR-7/PSR-15 pipeline lets the library plug in naturally. We gain standard grant types, token handling, and third-party interoperability out of the box, instead of maintaining a bespoke auth mechanism.
Migrate All System IDs to UUID
Adopt UUID v7 as the standard internal identifier for all data records, improving distributed uniqueness, sortability, and interoperability compared with the current ID scheme.
Using Codes as human-friendly IDs
Introduce codes as human-friendly identifiers that can be used directly in URLs to access a data record, as an alternative to the internal ID, making links more readable and shareable.
Thumbnail generation via the Renditions module
Extend the Renditions module to generate thumbnails for non-standard graphics and image formats, such as CAD, PSD, AI, TIFF, etc., improving previewability across a wider range of assets.
Versioning for Files (Digital Assets)
Retain all previous versions of a file when it is re-uploaded, preserving a complete history and allowing users to reference or restore earlier versions.
Simplified Views for Import/Export Feeds and Reports
Offer simplified views that hide complex configuration options from regular users who do not need to perform any setup, keeping the interface approachable for day-to-day work.
Channel-Based Languages
Allow channels to define their own set of languages. Depending on which channel is added to a project, users will be able to edit values only in the corresponding languages, and saving values for languages inactive on a channel will not be possible.
Near Future
(3 to 12 Months)
Two-Factor Authentication (2FA)
Add support for two-factor authentication, requiring a second verification factor in addition to the password at sign-in. This strengthens account security and helps meet common compliance and enterprise access requirements.
Improving Matchings
Extend matching to compare entity records as a whole, not just by explicitly selected attributes or fields. This enables holistic record-to-record comparison and broadens where matching can be applied.
Support for native JSON field types in PostgreSQL database
Add support for PostgreSQL’s native JSON field types, enabling more efficient storage and querying of structured JSON data.
Refactoring of the Change History and Notes mechanism
Rework the notes mechanism, which currently mixes entity change history and user posts in a single stream. The refactoring separates these concerns, splitting entity update records from user-to-user posts, and moves storage into dedicated per-entity satellite tables instead of one shared table.
Enable strict typing of the entity records
Introduce a new entity type to resolve the limitations of type-based entities. Entities such as Action or ExportFeed currently change shape by selected type, hiding or requiring different fields. This suits the UI but weakens the REST API, which must expose every field for every type, obscuring what a given type actually requires. The new type treats each type as a sub-entity with a strictly defined field set, making the API self-explanatory and the feature far easier to use.
Development of AI Agent
Introduce an AI agent that assists users by answering straightforward questions about how to use the system, lowering the barrier to entry and reducing routine support requests.
Data enrichment with AI
Extend AI beyond generating text and content to populating attribute values in line with their respective data types, enabling faster and more consistent enrichment of product data.
Using AI Engines in the Translations module
Add ChatGPT, Gemini, and Claude as additional translation engines within the Translations module. This update will include glossary support and improved translation quality.
Improving Reports
Enhance reporting by introducing caching for improved performance and by allowing reports to be used as standalone pages, not only as dashboard widgets.
Implementing simple configurable rules for ETL and Master Data Management
Introduce rules as an alternative to consolidation and transformation scripts, giving users a more configurable, lower-code way to define ETL and data pipeline logic.
Future
(12+ Months)
Full migration of the UI framework to Svelte
A large, long-running initiative: migrate the frontend 100% to Svelte and retire the legacy Backbone.js layer entirely.
Why this is better:
- Reactivity out of the box – Svelte updates the UI automatically on state changes, without Backbone’s manual wiring of models, views, and listeners.
- Less boilerplate – declarative, compact components; the same screen takes far fewer lines than a Backbone view/template/event setup.
- Better performance – as a compiler, Svelte ships no runtime and updates the DOM surgically, instead of Backbone’s full-view re-renders.
- A single, modern stack – consolidating the split Backbone/Svelte frontend onto one framework removes the cost of maintaining two paradigms and the glue between them.
- Component-based architecture – reusable, self-contained components with scoped styles replace the loosely coupled view/template pattern.
- Stronger tooling and typing – first-class TypeScript, better diagnostics, and an actively maintained ecosystem, unlike legacy Backbone.
- Easier onboarding – closer to modern web practice, so new developers ramp up faster than with an aging custom Backbone setup.
Improvement of AI Agent
Expand the AI agent to filter data records and create simple configurations for import feeds, export feeds, and actions, as well as to define data quality check rules, further reducing the expertise required for common tasks.
Refactoring of the archiving mechanism
Rework archiving so that archived records are physically moved out of the primary table into a satellite table, rather than merely flagged. Relocating archived rows reduces the size and load of the main table, which matters most when it already holds many records. The satellite table may even reside in a separate database engine, though this remains under discussion.
This relates closely to log-style tables such as Job or ImportJobLog, whose records have a short useful life and become clutter after two to three months. We are therefore considering automatic archiving of such records into a satellite table, or even a different DBMS, further offloading the primary database and reducing backup size.
Visual configurator for Workflows
Provide a visual configurator for building configurable workflows, allowing users to design and adjust process logic graphically rather than through manual configuration.
Under Consideration
The items below are ideas and directions we are exploring. They are not committed plans, have no timeline, and may change significantly or not happen at all. We share them to give insight into our thinking and to invite feedback.
Refactoring of the Access Management
We are still evaluating whether to rework the access control layer. Access levels are currently governed solely through ownership management and use of Teams. We intend to introduce flexibly configurable queries that determine which users may access which records.
Feel free to ask questions and suggest new ideas 