Comments
hi, This is a highly needed feature for us today. We are managing 10 live environments with potentially more to come. We need to be able to easily rollback deployments when something goes wrong during a monthly release.Currently, Business Central SaaS does not support direct rollback of extensions or environments after a failed deployment. Downgrading an app version requires manual uninstall and reinstall steps, and environment restores create new instances rather than reverting in place. This makes recovery slow and operationally complex for large organizations managing monthly release waves.It is a critical subject for enterprise customers managing frequent updates and customizations.
Below are the steps and settings required to reproduce the situation described above (images are not included, so the example is less detailed).We use three items:S00016 – Bicycle brake (rear)S00017 – Bicycle brake (front)W00008 – Bicycle brake (final product)Step 1: Item SetupOn the item card for S00017, the Reserve field is set to Always, so the system automatically reserves available inventory.Step 2: InventoryWarehouse PODSTAWOWY has 94 units of S00017.Step 3: First Prod. OrderCreate a Released Production Order for 94 units of W00008 and refresh. All 94 units of S00017 are reserved, confirmed in Reservation Entries.Step 4: Second Prod. OrderCreate another Released Prod. Order. No reservation for S00017 occurs because all units are already reserved.Step 5: Posting Without ReservationAssign lot/serial numbers and post consumption/output for the second order. A warning appears:“Reservation entries exist… Posting may result in negative inventory. Continue?”After confirmation, posting succeeds. The order shows 1 unit produced, and Item Ledger Entries confirm consumption.Step 6: Finish StatusChange the second order status to Finished; system confirms.Step 7: Impact on First OrderThe first order still shows reservations for 94 units, but only 93 units are available, and remaining quantity is 0. Despite reservations, inventory was consumed by the second order, making full execution of the first order impossible.
Adding more details for this topic.Background –The static segment had several limitations; we initially had a cap of around 100 contacts. This seems to have changed now but due to this constraint and based on the recommendation, we created a separate record that would eventually connect to a dynamic segment. Issue/Challenge –Our main challenge today is the complexity around segment refresh times. Different types of segment refreshes at different intervals anywhere from 30 minutes to 24 hours depending on how the segments were created. For users this becomes difficult to manage the logic behind the refresh time as it is not intuitive. So, it's hard to remember which condition led to which refresh delay. This becomes even more tedious when users want to build a segment with specific rules but only need to use it once. We usually plan and build journeys several days or even weeks in advance. And another thing is where we use our static segment that we needed to be created for the automation with dynamic segments and then we upload contacts to it. Here the problem is that the journey start date becomes unreliable and hence the emails are not sent. Possible solution - Ability to refresh the segment manually on UI.