Dear Forest Admin community,
Exactly 2 years ago, Forest Admin released the Development Workflow 2.0.
The goal was to answer to frequent customers requests, and especially developers from mature projects, that wanted to maintain their Forest Admin panel in a more fluid and collaborative way.
By the end of 2022, Forest Admin will entirely migrate projects to the Development Workflow 2.0 and shut down the legacy behavior.
As this migration might need some team synchronisation (especially for big teams), we want this migration operation to be under your control, supervision and planning.
If you decide not do the migration in the allotted time, Forest Admin will eventually do it for you, but it can have consequences if your environments are not properly flagged as “development” / “remote” / “production”.
We’ll go into details in the sections below.
The Development Workflow 2.0 introduces branches. This concept is certainly familiar to many developers. Forest branches will let them implement agent customization changes (as they have always been used to) and, then, apply layout changes to the admin panel in a named branch context (once for all).
Developers will, then, have the opportunity to push those branches in upper environments (test, qa, staging, pre-production,…) along with the code changes, to have a consistent application to use and test in the destination environment. Non-technical people can, in this environment, test the admin panel changes, validate the requirements in the admin panel and fine tune the layout if there are adjustments that need to be made.
Several branches, and their associated batch of layout changes, can also be pushed on the same environment and be aggregated in a consistent way to test several admin panel evolutions in a single environment.
Once everything is validated according to your QA processes, you are all set to make it live by deploying your code and layout changes batch in your Forest Admin production / reference environment.
Our CLI has been drastically improved to let developers manage all this using command lines.
Some customers also wrote deployment scripts using the CLI to automate as much as possible the redundant operations.
For technical reasons and better platform efficiency in the future, Forest Admin decided that, on January 1, 2023, all projects will run using the Development Workflow 2.0.
We strongly advise to all projects admins and developers that are still running in Development Workflow 1.0 to read our documentation (Development workflow - Developer guide) and learn how it could impact their current admin panel maintenance process.
Now, as a project owner, you have 2 options:
- Strongly advised: Take the time to schedule the migration with your team before the end of 2022. The migration itself should not take more than 15 minutes of your time.
- Discouraged: Let Forest Admin automatically execute the migration for you by the end of 2022.
First, you need to ensure you’re not already in version 2.0.
An indirect way to check your version is to go in your project general settings (
If you cannot edit the default environment of your project, congratulations, you are in version 2.0! You don’t need to worry about this topic, you are up to date.
If you can edit the default environment of your project, you are still in version 1.0 and need to do the migration.
The select is disabled once migrate to Development Workflow 2.0.
Be aware that only project owners with the “admin” permission level can handle that migration.
- Ensure your default environment is the “Production” one in your project general settings (ie the one that your company members use for their daily production operations).
It will ensure that the migration will update all other remote environment layout based on the right production / reference.
- Read on the dedicated page in our documentation and start the migration flow embedded in your admin panel settings.
What could go wrong if Forest Admin does the migration of your project automatically by the end of 2022?
The first and most important issue that could arise is the unexpected change of your admin panel layout configuration in production. It will happen if your real production environment is not the one Forest Admin flagged as production.
The second issue that could happen is the deletion of some important remote (test, qa, staging, pre-production,…) environments. It will happen if those environment are not flagged as “remote” but as “development” by Forest Admin.
The last issue that could happen is the deletion of all development environments (that will also happen if you handle the migration yourself) without having your development team members being:
- prepared for it,
- ready to create new development environments to resume their admin panel implementations,
- educated on the new way to push features and layout changes in the same bundle.
For all those reasons, we strongly recommend to project owners to do this migration manually. The migration wizard defines didactic steps that will make you learn along the way. As mentioned above, this is a 10 to 15 minutes operation, not more.