Are you in the process of implementing IFS?  Is that why you find yourself constantly moving up the profiles?  

Why are the changes being made in a Production or top-level environment and then being copied down to the test or development environments?

We normally only have to do this once, no more than twice on a new deployment at a location, so don’t find this to be a constant task requiring automation.  Just trying to understand the use case a bit.  We also warn new users to not go crazy making massive changes to their profiles and individualizing them in test environments.  We’ve found the time is much better spent learning to do transactions and use of the system and wait to streamline and personalize things until they are live or the design at least is finalized.

Hi @Manulak 

I would try to update TEST database FNDRR_CLIENT_PROFILE_VALUE_TAB with the relevant values from PROD :)

Quite a lot of good points, thanks @ShawnBerk 

Yes, we are in an implementation project but we foresee a lot of specific base profiles and personal profile changes anticipated by all the departments which will be on LIVE in few months. For the moment also we’ve already received a lot of master-user requests for their personalized base profiles per department, and we are not talking about 10s or 20s.

However, I totally agree with you. We are already trying our best to reduce the profile (UI alternation and distribution) overhead. The purpose of this post is to know if anybody has any bright idea to migrate profiles across installations, because we move next AST from one TEST to another due to data dependent decision. 

Thanks for the response, you smart fellow :-)

I already started this implementation, just because I did not see any other UI level solution. This post was to ask around if we have similar cases among the community, etc.

If I were successful, I’ll definitely share my solution with the community too.

@Manulak 

“Yes, we are in an implementation project but we foresee a lot of specific base profiles and personal profile changes anticipated by all the departments which will be on LIVE in few months. For the moment also we’ve already received a lot of master-user requests for their personalized base profiles per department, and we are not talking about 10s or 20s.”

I think you’ll find this sort of large number of profile changes and constant update a big headache to maintain from an IT perspective.  We started this way 7 years ago.  It was a mess. We now have the same base profile for about 80% of the users.  We found that most users don’t adhere to what is judged to be the master setup at the start anyway, so we just teach them to update their personal profile as part of the onboarding.  Later updates and patches just became unmanageable because the base profile alterations always break compared to the core.

My understanding is that Cloud is much, much worse in this regard with contexts, so I’m glad we’ve moved away from the high degree of base profile customization.

Good luck!

Thanks a lot for the inputs, @ShawnBerk 

This has already become a challenge and your comment makes much sense. We are already in the process of finalizing which departments need specific base profiles. I hope, after gathering information, there will be a clearer overview of the real business need behind such requests. Looking forward to it.

My current challenge is to automate the profile migration from one to another. My approach seems simple and works but let me update you and the community if I were successful.

Reducing the many-base-profiles issue > I’m totally with you, i.e. we should also get rid of that mess.

Hey @Manulak ,

Have you already tried export/ import from Explore profiles screen? there you can export as a bulk.

• Go to env1, Explore Profiles. Select all rows and Export Profiles

• In the env2, Import :)

I totally agree with the conversation about having many base profiles, don’t go for it, you’ll end up in a  mess.

Cheers!

Damith

Hello @dsj 

Absolutely yes, this is the way to go forward for IFS admiration point of view. Thanks a lot.

I am already in the process of implementing a one-click automation for this directly on the database level where it’ll backup, sync and override profiles via db links where necessary. Expected output is to reduce the IT administration overhead, as we already see that there’s a trend of a lot of profile (base and personal) alternations required in terms of the different parties involved (partner companies, etc.) in our nearing Go-Live.

wow, that would be really wonderful thing to have. Good luck bro!

This is just to share the promising solution I came up with to automate the profile management with reduced risk and overheads. Somehow, after few discussions, we’ve decided to stick to a single base profile until the initial Go-Live. Moreover, our IFS administrator uses the given import\export profile option on Explore Profiles window.

Simply, the current solution I implemented :

• A scheduled DB task which executes midnight daily which keeps track of profiles changes on FNDRR_CLIENT_PROFILE_VALUE_TAB
• It will then copy all the profile changes into an intermediate custom table (created via a Custom LU) with the composite key PROFILE_ID,DATE. Only 5 profile versions will be kept in this intermediate custom table, propriety with FIFO method

Now, both base and personal profiles are being version controlled up to 5 history versions.

• A Custom page “Profile Versions” will show archived versions per user, which shows the last 5 version in tabular format. The data can be controlled via a saved search if required, and an RMB “Revert to this version” is given which will update the personal profile lines of the FNDRR_CLIENT_PROFILE_VALUE_TAB with the intermediate custom table’s records.

Note : The user is clearly advised to do this in a fresh application session and immediately to restart after performing the profile reset, to avoid replacing the updated profile records from the current session closure.

Now, the database itself contains versions of all base and personal profiles.

Users can reset their own profile to a working version. We expect this’ll reduce the IT overhead, since our users are pretty new to IFS and probably may lead to crashed or screwed up profiles most of the time.

This runs for two weeks now, and all looks good for the moment.

Just FYI. Thanks all for actively participating in this discussion, specially @dsj , @Ruchira  and @ShawnBerk for ideas/ inputs.