--- title: Prohibited Behaviors and Integration Boundaries | Shopware Community Hub description: >- Understand which direct system modifications are not allowed for Store extensions and how to use supported Shopware extension mechanisms instead. canonical_url: >- https://hub.shopware.comhttps://hub.shopware.com/learn/unit/prohibited-behaviors-and-integration-boundaries --- # Prohibited Behaviors and Integration Boundaries - Use official APIs, DAL, events, services, and extension points effectively. - Plan technical integrations so they remain update-safe and maintainable. - Avoid risks caused by direct core, database, or file system modifications. - Align the technical architecture with Store Review expectations and long-term compatibility. # Prohibited Behaviors and Integration Boundaries Store extensions must integrate with Shopware without damaging the stability of the shop. This is why Shopware defines clear boundaries for what extensions are allowed to do and what they must avoid. These rules are not only formal Store requirements. They protect merchants from extensions that work at first but break during updates, weaken security, or interfere with core behavior in unpredictable ways. In this unit, you will learn which kinds of direct system modifications are not allowed and which Shopware mechanisms should be used instead. ## Why Integration Boundaries Matter An extension runs in a merchant's business-critical system. If it changes the wrong part of that system directly, the effect can be much larger than the feature itself. A direct database change, a modified core file, or a bypassed API may look like a fast solution during development. But it can create long-term risk: - Shopware updates may fail or behave differently. - Other extensions may no longer work as expected. - Security mechanisms can be weakened. - Merchants may lose trust in the extension and the Store ecosystem. The important mental model is this: > A Store extension should extend Shopware through supported mechanisms, not reshape the existing Shopware structure directly. This is the difference between a maintainable integration and a fragile workaround. ## What Store Extensions Must Avoid The not allowed behaviors documentation states that Store extensions must not directly modify the existing Shopware structure. This includes behavior such as: - direct database manipulation, for example executing arbitrary SQL from the administration - changing core table structures - writing, overwriting, or deleting files inside the Shopware core or existing directory structure - bypassing intended APIs, DAL, events, or services - undermining security mechanisms such as permissions, CSRF protection, or validations - enabling uncontrolled system interventions such as arbitrary file access or shell commands - bypassing legal or compliance-related mechanisms, for example consent or documentation requirements These rules are important because Store extensions are used by many different merchants in different environments. A pattern that seems to work in one local test shop can still be unsafe for the Store. ## What Store Extensions Can Use Instead Shopware does not prohibit customization. It expects partners to use the right extension mechanisms. Allowed approaches include: - using the Data Abstraction Layer (DAL) - creating migrations for extension-owned data structures - reacting to events - using subscribers - decorating services where this is supported - creating and using services - using documented APIs and extension points - copying existing structures, such as templates or assets, and adapting the copy instead of changing the original - creating extension-owned tables, entities, configuration values, or directories The extension fundamentals documentation also points partners toward standard extension structures. Following these structures reduces upgrade friction and prevents long-term maintenance issues. For a partner, the practical question should not be: "How can I force this change into the system?" It should be: "Which supported Shopware mechanism expresses this change cleanly?" ## Direct Changes Versus Supported Extension Points The following examples show the difference between fragile and supported approaches: | Goal | Risky Direction | Better Direction | |-----------------------------|-----------------------------------------------------|---------------------------------------------------------| | Store custom product data | Add columns directly to a core table. | Use custom fields or an extension-owned entity. | | React when an order changes | Modify core order processing code. | Use events, subscribers, or supported extension points. | | Change storefront output | Edit core template files. | Override or extend templates in the extension. | | Add extension configuration | Write values into unrelated system tables manually. | Use extension configuration and documented APIs. | | Change service behavior | Replace core code directly. | Use decoration where the service is designed for it. | This does not mean every supported mechanism is automatically the right one. Partners still need to choose the mechanism that fits the use case. But the direction should always be update-safe and reviewable. ## Alignment With Store Review The Quality Guidelines for Store Extensions describe Store Review as a process that checks quality, security, compliance, functionality, and behavior. Integration boundaries are part of that review. Reviewers need to see that the extension works with Shopware's architecture instead of bypassing it. This means partners should be able to explain their architecture: - Which data belongs to the extension? - Which Shopware APIs or services are used? - Which events or extension points are involved? - Which changes are isolated in extension-owned code? - How does the extension behave during install, update, deactivate, and uninstall? If these questions cannot be answered clearly, the architecture may not be ready for Store Review. ## Example: Adding Data to a Product Workflow Imagine a partner wants to store additional product-related information for their extension. A risky approach would be to directly add columns to an existing Shopware product table or update that table through manual SQL. This creates upgrade risk and makes it hard for Shopware, the merchant, and other extensions to understand who owns the data. A better approach is to use a supported mechanism. Depending on the use case, this could be a custom field, an extension-owned entity, or a migration that creates a clearly assigned extension table. The feature may look similar from the merchant's perspective. But technically, the second approach is easier to review, easier to maintain, and safer during updates. ## Common Pitfalls ### Solving a Local Problem With a Global Override A direct core change may solve one problem quickly, but it can affect every shop process that depends on the same structure. ### Treating the Database as the Main Integration API Shopware provides APIs, DAL, services, and events for a reason. Direct SQL against core structures is not an update-safe integration strategy. ### Ignoring Security and Legal Boundaries An extension must not bypass permissions, validations, consent mechanisms, or legally required processes. These are part of the platform's trust model. ### Waiting Until Store Review to Check Architecture Integration boundaries should shape the architecture from the beginning. They are not details to fix shortly before submission. ## Summary - Store extensions must not directly modify the existing Shopware structure. - Direct database manipulation, core table changes, core file changes, and API bypasses create update, security, and review risks. - Supported mechanisms include DAL, migrations, events, decorators, subscribers, services, APIs, and documented extension points. - A Store-ready architecture should make ownership, integration points, and lifecycle behavior clear. - Planning within Shopware's extension boundaries helps partners build maintainable and review-ready products. Next, you will look at functionality, configuration, and external services so merchants can use the extension confidently after installation.