Security "Reset" When Prod is Copied to Dev

That is likely happening because your security framework in your PRD environment is not in sync with your DEV environment.  The security framework (users & groups) exists outside of each application database in an environment.  So then when you copy an app from PRD to DEV and in PRD you have used security groups in an app (as your screen shot above) in PRD that do not exist in DEV, they will show up as "(Not Found)" in your DEV copied app.

I am not 100% positive of how to resolve.  You could open a case with OS support to get the steps but I think one option is you can extract your security (groups specifically) from PRD and load to DEV before your app copy. That way when you do copy the app from PRD to DEV, the groups that are referenced will exist in the DEV environment and get associated when the app is copied over.

I think there may also be a way to copy your security framework database from PRD to DEV too.

Again, your best bet may be to open a case and search OS's knowledge base articles for the steps to resolve.

But this does not surprise me if your security is out of sync that you are seeing "(Not Found)".

T_Kress is on the right track - the problem is that the Framework database in your 2 environments are not the same (and that is normal). The problem though is that the metadata security groups are stored in the database using their unique ids not the name and while the security groups might be in both environments, they have different unique ids. The way to solve this is to update the security groups in DEV with the PRD groups but you need to select 'Extract Unique IDs':

That will load/update the security groups using the same unique IDs as PRD.

It might also mess up the user security assignments in DEV. So the steps you need are:

1. extract DEV security without Unique IDs
2. extract PRD security with unique IDs
3. load PRD security extract into DEV
4. load DEV security extract into DEV to reset the user assignments

I think that will do it but I haven't tested it.

In short:

• copying applications at the Database level (including all data) will copy any Security Group references by Guid.  That's not a problem so long as you are copying within the same Environment, as all apps share the same Framework Database, where Security is defined.  The problem occurs when copying apps between environments where Security Groups may have been created manually in each environment, and thus will have different internal Guid's between the environments.
• Extract/restoring an app via XML will reference Security Groups by Name (not Guid).  Upon restore, OS will convert the Security Group references to the Guid's for that of the environment the app is being restored to.
• If you manually create the same Security Group in two Environments, they will each assign a different internal Guid.  Internally OS uses the Guid throughout as the Security Group reference.  Same sort of deal occurs with dimension Members which will get a unique MemberId, among many other objects in OS.  But Security Groups can be problematic, as they are assigned in the Framework database which is shared across all the apps within an Environment.

If you think you are going to need to be copying apps between environments, you really need to make sure you always use the copy the Security with the Extract Unique IDs option enabled to make sure the users and groups share the same internal Guid's between the two environments.  The members of a security group do not need to match.  But the Guid's (especially of the Security Groups) really do need to match, else you will run into problems when you start copying apps between environments.

Once you see the Security Groups of a restored app are messed up, I have found the following solutions work (there might be other options):

Option 1 - Delete the Security Group having a non-matching Guid on the destination side and then export/import the Security Group with the Extract Unique IDs (Guid's) checked.  Do that for each of the Security Groups where Guid's do not match between environments.  Restart OS the destination side - that is a must, as OS caches a lot of this info in memory.  That usually gets the broken Security Group references back in the restored app.  This option is really only viable if the destination environment does not have any other apps that could also be referencing Security Groups for which you changed the Guid's, otherwise you will break those apps when the internal Guid's change.  Hence, why you really want to keep the Security Group Guid's in-synch between environments from the get go.

Option 2 - After restoring the app Database and seeing there is a problem, then export the entire app (everything but FX Rates) from the source app via XML, then restore that overtop of the messed-up destination app.  Since the XML files reference all Security Groups by Name (not the Internal Guid),  OS will reassign the Guid's to that of the Security Groups it finds.

Option 3 - If you don't care about the Security, there is a Marketplace solution that will perform a search and destroy through an XML extract changing all the Security Group References to Everyone, Administrators, etc.  This would be a slight variation to option 2.

There is a Knowledge Base (KB) article on this as well, here:

OneStream Customer Support - How to Keep the Security Synchronized Between Two Environments | OneStream Software - ServiceNow