You are allowed to make changes to network features when they are in Draft mode (not published to the ItsOn server or to any embedded-client devices), Test mode (when the existing feature is already pushed to devices that you're using for policy testing) and in Published mode (when the existing feature is already pushed to the ItsOn server and to the embedded-client devices of your customers). Changes to network features are immediate, and are published to the ItsOn server immediately and to embedded-client devices as soon as they "check in" with the network (typically within 24 hours, or when the device is reset), or, when a network feature is moved from Draft to Test status, immediately.
Exception: Once a bucket ID, rating group, or entitlement code has been added to a network feature, it cannot be deleted. It can only be changed, and only until the network feature has been published. Once a network feature that uses a bucket ID, rating group, or entitlement code has been published, the bucket ID, rating group, or entitlement code in the network feature can no longer be changed.
You can:
Because they are potentially controlling the behavior of many ItsOn-powered devices, you should be cautious when making changes to published features. If changes are minor, editing an existing feature that is already published could be a reasonable option. If more substantial changes are desired, a different approach might be recommended, one where you create a new feature that replicates the components and policy events from the original, make the changes you want to the replicated feature, and then take it through your normal draft-test-publish workflow, which may also include testing on a larger number of production devices.
In either scenario, one very important consideration is to review and evaluate how all your published features are configured so that there are no policy conflicts.
Replicating a feature is the process of making a new feature starting with the same components and policy events of an existing working feature, one you have already tested and publish and you know is working, so you have a valid starting point to make significant changes.
As you take the new feature through the draft, test, and publish process, review the component and feature configuration of the two features carefully to make sure the policies do not conflict.
Once you have migrated all your embedded-client devices to the new feature, you may want to delete the old feature.