This scenario helps you bundle system components into a single solution and prepare it for export, installation, or update. You will define the solution composition, check for external dependencies, generate an .e365 file, and import it into another company environment.
A solution in BRIX is a set of related system components designed to handle common business tasks. It can include workspaces, apps, pages, business processes, widgets, scripts, modules, and other custom settings.
For example, the Procurement solution streamlines goods and services workflows across your organization. It can feature a dedicated workspace, several apps for storing data, a business process to handle approvals, and user pages.
When to use this scenario
Preparing a solution is necessary to:
- Bundle configured functionality into a single package for easy management.
- Transfer settings from a test environment to production.
- Deliver a ready-to-use configuration to another company.
- Release a new version of an existing solution.
- Export data to an .e365 file for backup or import.
This scenario shows the overall configuration logic and does not replace detailed instructions. At each step, you will find links to help articles with detailed descriptions of the required actions.
Before you start setting up
Before creating the package, map out the architecture and logic of your future solution. Be sure to define the following:
- Workflow scenario: The specific tasks users will perform within the scope of the solution.
- Solution composition: The components that should be included in the package.
- External dependencies: The components that shouldn't be included in the package because they are already present or configured in the target company.
- Future development plan: Whether the solution will need adaptation after installation or future version updates.
If you plan to develop the solution further, map out how updates will be released and installed in advance. This will help you choose the best structure, such as which components should belong to the main package and which should be delivered as additional modules.
For example, if you are preparing a Procurement solution, identify all components it will add to the company: a separate workspace, apps for requests and suppliers, an approval process, user pages, or custom modules.
Step 1. Define solution boundaries
First, identify which components will be part of the solution package and which will remain external dependencies.
A solution should only contain components that belong to a single workflow scenario or product setup. We do not recommend bundling all company settings into a single package.
For example, the Procurement solution can include:
- The Procurement workspace.
- The main Purchase Orders app.
- Reference apps like Suppliers and Products and Services.
- The Purchase Order Approval business process.
- Required user pages.
- Widgets, scripts, and other settings essential for the solution to run.
Keep track of dependencies separately. For instance, a solution might use components from a built-in workspace, another solution, or a licensed product. These dependencies must be accounted for before exporting and importing.
Начало примечание
Useful articles:
- Solutions in BRIX describes solution types and the components they can include.
- Create a solution from scratch explains how to create a custom solution and add components to it.
Конец примечание
Step 2. Create a solution and add components
At this stage, you don't need to configure apps, processes, or pages from scratch. You simply bundle pre-configured components into a single package so you can transfer or update it as a single unit.
Keep these rules in mind when adding components:
- A custom workspace, module, or company-level page can belong to only one solution.
- A built-in workspace can be added to multiple solutions since it exists in every company environment by default.
- If a solution includes only a part of a built-in workspace, you must select specific apps and components manually.
For example, if the Procurement solution uses a dedicated custom workspace, you need to include that workspace in full. If the solution relies on standard platform components, decide whether to include them in the package or keep them as external dependencies.
Начало примечание
Useful articles:
- Create a solution from scratch explains how to create a custom solution and add components to it.
- Build solutions in BRIX describes how to extend platform capabilities using custom solutions.
Конец примечание
Step 3. Check dependencies before export
Before exporting the package, review the solution to ensure it has no links to components that are missing from the package. Do this before running the automatic check during export.
This step helps you determine in advance which objects must be included in the solution and which should remain as external dependencies.
If a component inside the package links to an object outside it, the solution might not work correctly after installation in another company.
Examples of external dependencies:
- An app from another workspace that isn't included in the package.
- A page or widget missing from the solution.
- A business process that belongs to a different solution.
- A link to an organizational chart element.
- A component of a system solution or licensed product.
- A script referencing an object missing in the target company environment.
Based on your check, add any missing components to the package or list the prerequisite settings that must be configured in the target company environment beforehand.
Начало примечание
Useful articles:
- Solutions in BRIX describes which components can be included in a solution and how to manage their links.
- Create a solution from scratch explains how to add components to a custom solution.
- Export a solution to an .e365 file describes how automatic checks for external dependencies work during export.
Конец примечание
Step 4. Prepare details for export
Before starting the export, draft a brief description of the solution. This information helps the target company's administrator understand the purpose of the .e365 file and follow technical requirements during installation.
Detailed information is especially important if the solution is being shared with an external organization.
We recommend including the following details in the description:
- The purpose of the solution.
- The main components included in the package.
- The workspaces, apps, or pages created after installation.
- Solution dependencies.
- Licensing requirements, if applicable.
- Initial setup tasks the administrator needs to complete after import.
For example, for the Procurement solution, you can specify that it adds a workspace for purchase orders, apps for suppliers and products, and an order approval business process.
You can add solution details directly in its card before export, or during the export process in the next step.
Начало примечание
Useful articles:
- Create a solution from scratch describes how to open a solution page and fill out its description.
- Export a solution to an .e365 file explains how to provide solution details during export.
Конец примечание
Step 5. Export the solution
To build the solution package, export it to an .e365 file.
An .e365 file can be used to:
- Install the solution in another company environment.
- Move the solution from a test environment to production.
- Hand over the solution to another administrator.
- Back up a solution version before making changes.
During export, BRIX automatically analyzes the solution components and their links. This check flags components used by the solution that are not included in the final file.
If the automatic check flags errors or critical dependencies, stop the export. Adjust the package composition or add missing dependencies, then try exporting again.
For example, if the Procurement solution uses the Suppliers app, but it is not included in the solution and missing in the target company, you need to add it to the solution or include it as a dependency in the exported file.
Начало примечание
Useful articles:
- Export a solution to an .e365 file describes how automatic checks for external dependencies work during export.
- Import a solution from an .e365 file explains how to work with the exported solution package file.
Конец примечание
Step 6. Import the solution
To install the solution in another company, import the .e365 file.
During import, the system verifies that the solution can be installed smoothly. It checks for conflicts with existing components, duplicate pages, setting incompatibilities, or missing dependencies.
Before importing, check the following:
- System version: If the solution was created in a newer BRIX version than the target company environment, installation might fail or run improperly.
- Licenses: If the solution uses system solutions or specific BRIX product features, active licenses may be required in the target company.
Начало примечание
Useful articles:
- Import a solution from an .e365 file describes how to install a solution from a file and what checks run during import.
Конец примечание
Step 7. Determine if unlocking is needed
After import, you can use the solution as-is or customize it to fit your company's needs.
Choose an operating mode based on your goals:
- Unlock the solution: Choose this option if you need to make changes, such as adding fields, modifying forms, or adjusting processes, pages, or modules.
- Keep the solution locked: Choose this option if the pre-configured workflow logic fully meets your company's requirements.
When creating a solution, an administrator can allow users to edit individual app contexts without unlocking the entire solution package.
Commercial or external solutions might require an unlock password to protect them from accidental edits.
Начало примечание
Useful articles:
- Unlock a solution explains when to unlock a solution to make changes.
- Protect a solution with password describes how to restrict unlock permissions for a solution.
Конец примечание
Step 8. Prepare a solution update
If a solution is already installed in your company environment, new versions are installed by updating the existing package rather than uploading it as a separate unit.
Before updating, check the following:
- Which components have changed.
- Which settings should be replaced and which should be kept.
- Whether local customizations exist in the installed solution.
- Which update mode to use: full update or soft update.
A full update replaces the old version completely. A soft update preserves the components that administrators have customized in the target environment.
For example, if the forms or processes in the Procurement solution were modified locally, decide whether to overwrite them with the new version or keep the local changes before running the update.
Начало примечание
Useful articles:
- Unlock a solution explains when to unlock a solution to make changes.
- Update a solution describes how to update an installed solution and choose an update mode.
Конец примечание
Quick recap
- Identify the user goal or task the solution addresses.
- Bundle ready components into a single solution.
- Verify how the parts interact and ensure there are no links to unincluded components.
- Draft a solution description for administrators.
- Export the solution to an .e365 file. Fix any errors flagged during the check.
- Import the solution into the target company environment after verifying system version and license compatibility.
- Unlock and adapt the solution in the target environment if needed.
- Deploy future version updates by applying solution updates rather than reinstalling.