You should be able to export the configurations as ACPs, which will at least retain what you’ve done.  You can see some steps for best practice here:

However, to reset the Global context, you will likely have to recreate the environment (hopefully you aren’t live already) so you have a clean installation.  Then create a new context, we created one named with the company name and Global to differentiate, i.e. “Company Global”.

The tricky part will then be importing the saved ACPs but directing them to the new context rather than the one they are saved in from the previous environment.  That part I’m not sure how to make work as I haven’t done it.  You should be able to try that out within the same environment, export, create the new context, then import to the new context to make sure it will all work.

You definitely don’t want to modify the Global context as it makes dealing with future releases very problematic as they won’t get recognized if the Global context has been modified without unpublishing the configurations then publishing them again after the changes are picked up.

When we import ACP, we do not have the option to select context it should go. That means it is by default imported to context set in ACP. How do we change it?

@ShawnBerk - If you don’t modify the Global context, do you have any suggestions on how to make changes that everyone should see but also have custom context for certain screens? We have scenarios where certain groups need to see specific screens differently than everyone else. 

When we import ACP, we do not have the option to select context it should go. That means it is by default imported to context set in ACP. How do we change it?

That is unfortunate...as I said, I don’t know how to make it work.  It may require reaching out to IFS to see what they suggest since they don’t make it clear in the initial setup and turnover that it is a really bad idea to modify the global context.

@SaraCrank 

You can make a new company centric Global context that contains everything that you need everyone to see, then make a third one that is customized to a particular group of users as needed.  It is at least flexible in that regard.  Just remember that for every additional context you have, when you get updates and service releases, those contexts will have to be unpublished and republished to pick up the changes that you will be able to see in the Global context.  With the flexibility comes an enormous growing maintenance debt to maintain the software.

This is when you come to the realization that the evergreen model simply means pushing down all of the maintenance and headache to maintain to the customer.  If you forget or mess it up or don’t have a tightly controlled mastering schema, you end up either losing the configuration changes you’ve added when you apply an update or you don’t get the enhancements added by IFS because they don’t get applied to custom contexts without manual work.

Thank you for the info! Since we’re in the beginning process of transitioning, we’re trying to figure out best practices to creating and maintaining the contexts. In your experience, if you have to have multiple contexts, what’s the best practice? We’re also trying to figure out the best way to package them up into ACP’s to move between environments. 

Any advice you or anyone else has would be greatly appreciated. Thanks!

We are keeping the IFS Global context untouched, then all new changes in releases can be seen directly in the IFS Global context, but we don’t want any users to see or use the IFS Global context.

We are trying to force all users to use the Instron Global context which is the company global view for 95% of the configuration changes.

On the handful of pages so far where we want one version for everyone (view and analysis type users mainly) and a different context for data entry, then we create a third that is given to a limited set of users.  We keep track of these exceptions so we only have a small number to manage and we really analyze whether this difference is needed before enacting it.

For the ACP packaging, you can do it by page, but that becomes too granular.  We think from experience that doing it by large process areas or functions is best and rolling up all of those things in one ACP becomes a bit easier to manage as there aren’t as many of them to keep track of.  It somewhat matters how many different analysts/developers are making changes and whether you are storing the master in the Build Place or in an outside of IFS repository.  You want to be able to really keep track of the revisions (small control group), but you don’t want to so lock it down that multiple analysts or groups can’t work in the same area.

We are trying to require some documentation in our change management system as well so there is a change record as to how, when, why, and who created the change and to which environments it has been checked or deployed, but that is still and evolutionary process.

I don’t know there is one correct answer for every installation, but that is the most general guidance I can offer.

Just came across this thread an I'm now concerned about our environment.  We are currently on IFS Application 10 and just beginning our upgrade to IFS Cloud 22R2 with a plan of going live with 23R1.  We have been putting custom fields in global context in IFS 10 for the limited use of Aurena.  Sounds like we may need to roll these changes out of global context and into another context before we migrate data.  I didn't see anywhere in docs recommending to not use global context.

I guess I have some questions for consultants and IFS as we upgrade.  Does anyone know when upgrading from IFS 10 to Cloud if the Aurena customizations are migrated to IFS Cloud or if we need to redo them?

Regards,

William Klotz

@ShawnBerk - Thanks for the info! You mention multiple developers, have you had any experience with multiple people working on the same projection at the same time or do you break your work down by page?

There are some configuration best practices defined on this page.
 

Specifically related to using context it says:
 

When not working in any specifically-defined context, you are in the Global context. It is a good idea to keep the Global context vanilla (i.e. unconfigured). If you type “scope=999” (where 999 is not a scope that actually exists) into the URL you will get to view the global context. Having the Global context unconfigured makes it easy to "sanity-check" new customization deliveries.

I am thinking of what are the benefits of keeping the global context intact?

• After IFS update/delivery, clearly reflect the new update to the user from global context if it is intact
  • can we achieve same by taking ACP backup and unpublishing the global context changes and reimporting ACP from the backup?
  • or just unpublish and republish works will result the same? 
• any other benefits?

@SaraCrank 

have you had any experience with multiple people working on the same projection at the same time or do you break your work down by page?

You can have multiple people work on the page or different aspects of it at the same time, but the way we broke the work down we tried to avoid it simply because of possible conflicts more than anything, but it is possible.  Someone just has to be responsible for rolling up all of the changes into an ACP and knowing when done is done.

• can we achieve same by taking ACP backup and unpublishing the global context changes and reimporting ACP from the backup?

IFS is not going to tell you where they’ve made changes or what the change might affect, so unless you have a plan to go and unpublish and republish every configuration change in every ACP for every update even a service update, you won’t know what changed.  We’ve not found any better way to do this than as I’ve explained.  I’ve heard from other customers who were deploying Aurena early on in V10 with a similar experience.

The answer to the original question is that there is no current application support to move Page Configurations between context. So besides database scripts or manually modifying ACP’s (Not recommended, nor supported), the only way is to manually re-create the configurations in the wanted context.

-Of topic

Not an answer to the original question. I just post this because a big portion of this thread have been about global or not. So I just add a small note around this. If there are further inquiries about that. I suggest you start a new separate thread for that. 

@ShawnBerk - With the rebase tool introduced in 23R1, you will now see what changes IFS have made. Well not every change but the changes that IFS made in the client for the same artifacts that you have configured. This also means that you get to “merge” your configurations with the delivered changes.