24R1 - Global Context Best Practices

1. Page configurations in the global context are not wiped when updating the instance. Instead, they’ll be flagged as being behind the “baseline” in the Page Configurations page. You can then use the Page Designer to apply the new baseline changes. The process is described in the tech docs, but I found it fiddly and temperamental, with the Page Designer being a little too keen on overwriting your tailoring. I recommend simply just practising in a dev environment: https://docs.ifs.com/techdocs/24r1/040_tailoring/225_configuration/200_client_configurations/400_rebase_configurations/
2. I’m still trying to work this out myself, and I’d say “it depends”.
   • On one hand, keeping the global context “vanilla” makes it easier to go back and check what the core application looks like.
   • But if you have multiple contexts, because different users need different configurations of the same page, then the global context is useful for putting common configurations. Note that each user can only be assigned one “specific” context.

On a side note, it would be nice with some sort of “ordinal” on configuration context mappings, like there are for report rules etc., so that the application keeps looking for a page configuration until it finds a match in a rule. At the moment, say you map contexts by user group, and put a user in two groups, the application bombs out because it doesn’t know which context to use.