Using program PFCG_ORGFIELD_CREATE

[Former Member]

Hi,

I am using the derived roles concept for creating roles. I want to add an organisational level to some of my roles, but am unsure of the consequences of using PFCG_ORGFIELD_CREATE to do this.

1) When I take an authorisation object and add it as an organisational level, will it change in all roles containing that authorisation object across all transactions?

2) I am working on a project in a validated environment. I would like to transport my roles from DEV to QA environment, but have read that I would need to make some changes in QA for the roles to work. What exactly would I need to change after transporting the roles?

Thanks

[former_member74904]

hi gary,

when creating org. levels it will affect all roles. it is generally not advised to create org. levels once your role structure is in place. you're normally supposed to do this before you start designing your roles.

however, I have done this when the roles were already there, and I got away with it without any discrepancies.

please also read this note: 323817

to answer your second question: you should also run this program in QA as the ORGFIELD_CREATE program is executed client-independently.

subsequently, this program must also be run in PROD.

[Former Member]

thanks Dimitri,

should the program be run for each organisation object created in Qa and DEv, so I presume this should be done before the roles are transported across?

Also I am using GRC- compliance calibrator. I don't suppose you have any idea if adding additional organisational objects would affect how this works?

Thanks,

[former_member74904]

gary,

yes, you can only run the program for one org. level at a time. and this should be done in all clients (DEV, QA, PROD) you can decide when you want to transport your roles to the clients 'above' DEV, but you may encounter some undesired behaviour when transporting roles with org. levels included without them being available in QA and PROD yet. so just to be sure, create the org. levels first.

I'm afraid I can't help you with the GRC part of your question...

good luck!

[Former Member]

thanks Dimitri,

I would like to test this to find out if there are any impacts on GRC. Can the changes be reversed easily?

Niamh

[former_member74904]

hi again gary,

well, you can delete the org. levels again with PFCG_ORGFIELD_DELETE, but I suppose the damage, if any, will have been done by then.

I suggest downloading all of your roles locally before running the CREATE program and if you find any inconsistencies upload them again after you delete the newly created org. levels. I personally doubt that you will encounter any unresolvable issues, but don't let my gut-feeling get in the way of your decision )

[Former Member]

You may want to check your rules & risks in CC to see if any of them rely on the field.

From memory CC works on the auths at the profile level, in this instance the profile fields do not differentiate between a value being org level or non org level.

Definitely worth testing though!

[Former Member]

Hi Dimitri,

I just ran the program and found that this program caused a cross-client impact. The filed has been converted to org.level in all clients. Even we tried to run individually in another client, the system was indicated that this field has alr a org.field.

Not sure if you facing the same problem before, maybe you can give me some advice on this prob?

Thanks,

[mvoros]

Hi,

the org. level fields are stored in table USORG. This table is client independent. Hence activating field as org. level field in one client will have impact on all clients. So you can't do anything about it. It's also indirectly mentioned in documentation for this program.

The organizational level field is created across clients, however, the report changes the roles only in the current client. Therefore, you call up the report in all clients.

Cheers

[Former Member]

Thanks Martin,

Can u plz further advice on "the report changes the roles only in the current client."

The "report" here is meaning which report?

thanks,

[mvoros]

report = PFCG_ORGFIELD_DELETE. Just run it and click on icon with letter i in blue box (Shift+F1). It gives you documentation for this report.

Cheers

[Former Member]

Thanks,

But what make me confusing is - by right the report should only change the role in current client, however after I checked in system, roles in the rest of the clients have been changed as well - the authorization field becomes an org.level field and the org.value data is entered for the role, which meaning I have to regenerate for some of the roles.

Is that usual?

Thanks,

[Former Member]

Thanks,

But what make me confusing is - by right the report should only change the role in current client, however after I checked in system, roles in the rest of the clients have been changed as well - the authorization field becomes an org.level field and the org.value data is entered for the role, which meaning I have to regenerate for some of the roles.

Is that usual?

Thanks,

[jabella]

Hi Garry,

First of all, you will not convert an authorization object, you will convert an authorization field to org level. The result will be, that all the authorization objects including the field converted will be affected and in consequence, all the roles containing an authorization object with that field will be modified and will need to be adjusted.

Once you do that in DEV, you will need to go to QAS and PROD and do the field conversion. The conversion is NOT transportable. After you do the change, you can transport the roles updated in DEV. If by mistake you transport the roles before doing the conversion, you will see that the value of the auth field is not the value given, but instead the value $<name> is set. To solve this, the fastest way is to do the conversion and transport the roles again.

Regards, Jose

[Former Member]

Are there any recommendations witch authorization fields that should be converted to organization level?

All the best

Anders

[jurjen_heeck]

> Are there any recommendations witch authorization fields that should be converted to organization level?

The best recommendation I know is common sense (no offense meant). I do not know of a rule or a set of fields that apply best.

If a field is used within your company to represent (a part of) the organisation it could be handy to 'upgrade' that one to organizational....