If one object is located in package A and second in package B, updating package A will not interrupt data from package B.
If you are developing on dev instance and installing the package from dev to prod this package will be locked and no changes will be saved to it.
If you are trying to change unlocked package to locked it will most likely lead to installation issues or functionality issues.
Since it is not expected for new features to be developed on production application you can use Custom package for minor changes.
The prefix should be the same as on dev and it should not interfere with existing customisations (if there are objects on schemas with "Usr" prefix it is not recommended to change prefix).
That's exactly how we are working . We are using the same prefix as our custom package that was imported from Dev.
When a production user tries to save a new process,
...he/she gets the message:
... and if he/she is allowed to save it, my concern is also if this new process will be preserved when a new version of the package is imported from Dev.
That is exactly what the problem is. The package IS locked in production, as it was imported from dev. What is the solution for that ? Should we have another custom package in the prod environment specifically for that, where users can save their campaing processes ?
Thanks. That is the solution we have adopted. The only difference is that we have created another custom package, instead of using the "Custom" package.
