Choosing a Safe Change Window in EDGEBIC

In EDGEBIC only the database connection needs a restart. Role changes take effect at a user's next sign-in, scheduling policy lands on the next scheduler run, and display settings apply as soon as you save them. In EDGEBIC by User Solutions knowing which is which decides whether a change needs a quiet window, a notice to the team, or neither. This post is the timing table an administrator plans against.

The individual settings are mapped in a tour of the options and settings. This post is about when to press save.

The Timing Table

The interesting column is the last one, because two rows need announcing for reasons that have nothing to do with downtime.

The Three That Need Everyone Out

The database connection. Switching the provider or the target database on the DataSource tab always requires a restart, and the application closes and reopens immediately, so in-progress edits should be saved first. The bigger reason to schedule this properly is that the switch does not move data: the database you leave keeps everything and the new one starts empty, built with a full schema on first connection. That makes the switch a migration rather than a setting, and migrations done in a hurry are the ones that go wrong. Use the dialog's one-click export of the database you are leaving, then re-prove the loop on the new one by running the scheduler on real orders. The full procedure is in switching the datasource.

An upgrade. Back up first, upgrade, let the database update itself on first launch, verify before anyone signs in. Then review the custom roles, because new permissions land automatically on the built-in Administrator role only. See upgrading safely.

Data clearing. Permanent row removal with no recycle bin, guarded by a red banner and a confirmation word you have to type. Take a backup first, every time, and get a second person to agree before you type it. The utility and its scopes are in the data clear tool and when to use it.

The Ones That Need No Window But Do Need a Word

Role and user changes are safe to make at any time, because a person's rights load when they sign in. A change made while somebody is working reaches them at their next sign-in, and an administrator on the same machine sees it immediately, which is exactly why an administrator often reports that a permission works while the affected planner reports that it does not.

Two habits follow. First, when you grant something, tell the person to sign out and back in, and when they say it still is not there, have them do that before you investigate anything else. Second, when you remove something, tell them why beforehand. A control that silently disappears reads as a fault, since screens and buttons a user lacks permission for are hidden or refused rather than shown and disabled. The common failures are collected in user and permission mistakes.

The One That Needs No Window and the Most Notice

Scheduling policy is the trap in this list, precisely because it is so easy.

The Schedule tab holds seven site-wide choices, and none of them needs a restart: policy is read fresh on every scheduler run. Save on Friday afternoon and Monday's plan is different, with no downtime, no prompt, and nothing on screen saying a rule changed.

Consider the clearest example. Flip the default scheduling direction from forward to backward, and every new job and quote is placed just in time so the last step ends at the due date, with spare time deliberately sitting in front of the work instead of after it. Existing orders keep the direction they were created with, so the change appears gradually as new orders arrive. To a planner who was not told, that reads as the scheduler behaving oddly for a fortnight.

The same applies to the doesn't-fit action (whether a backward job that cannot make its date is quietly accepted as the earliest forward plan or pauses for review), and to partial-confirm behavior, which decides whether a short confirm's missing hours are written off or forward-shifted into a future slot with downstream steps queuing behind them.

So the rule for policy is: change it at a quiet moment, tell the team before you save, and write down the date and the reason. That last part matters because the software records the value and not the argument, which is the whole case for a written conventions document, covered in documenting your plant's conventions.

The Ones That Need Nothing

Display configuration is per user and per machine: colors, bar labels, overlays, timeline range, what a drag is allowed to do. None of it changes the engine's math, so two planners can configure their screens completely differently and still see the same underlying plan. Grid and panel layouts likewise save per user automatically. Change these whenever you like; any view's configuration dialog has a Reset to Defaults button when an experiment goes too far, and layouts are covered in administering grid layouts.

One More Reason to Pick a Window

There is a second, quieter argument for doing administrative work at a quiet moment: saves follow a last-write-wins contract. Two people saving the same record in the same window means the second overwrites the first silently, including fields the second person never touched. Two administrators tidying settings on the same afternoon are the classic case. That behavior and the ownership habits that prevent it are in what happens when two admins save the same record.

Plan changes against the timing table, announce the two that change the plan, and administration stops being something the plant notices. For the full administrator reference, read the EDGEBIC admin guide; for the review rhythm these changes should be batched into, the quarterly admin health check; and for the fundamentals the policy settings govern, what production scheduling is.