PTC Admin Center: What is the purpose of Groups?

[Robrecht]

Since the release of Creo+ and the PTC Admin Center I've been playing around and exploring the possibilities of the platform.

One thing I can't seem to get a grasp of is the purpose of the Groups inside the PTC Admin Center.

So far, you can create, edit and delete groups and add/remove people to a group but it seems like there is no functionality linked to these self-created groups outside of the Groups tab.

I tried searching the help centers and documentation and I only found a page explaining how to add/edit/delete groups but it doens't explain what you can do with Groups in the Creo+ Portal or the PTC Admin Center:

https://support.ptc.com/help/ptc_saas/admin/en/index.html#page/admin/Create_Groups.html#

[MartinHanak]

Hi,

did you ask the same question to PTC Support?

[Robrecht]

Hi @MartinHanak 

I opened a Support case for this question last week, but didn't get a clear answer until yesterday after I already created this forum thread.

[mfischer · Accepted solution]

Hi @Robrecht,

The groups within the Creo+ Admin Portal (soon to be renamed to Profiles) can be easily created by your local admin and include a set of users.  These profiles can specify different configurations, default language and floating options.  Users added to a one or many profiles, can choose the desired profile they want to run Creo+ with.  

For on-prem, many customers utilize PSF files to control this.  Since Creo+ does not offer PSF anymore, we leverage profiles.

Let's take for example 3 departments - Engineering, Manufacturing and Analysis.

You can create three profiles...one for each.  Each profile can point to its own configurations (config.sup, config.pro, customization.ui, library files, etc.).  In addition, the admin can add the necessary floating options needed by that group to the profile.

From the PTC Control Center, the user will see their given profiles and choose which one to start using with Creo+.  Selecting the given profile, will have Creo leverage the profile configurations and which floating options they would have access too.  In the future, we will leverage the profile to include things like which customizations the user can access or which environment variable need to be applied.

The goal is to allow the user to choose the profile to run Creo in the right context for their role, department, office or region.

Hope that helps.

Mark

[Robrecht]

Hi @mfischer 

Thanks for the detailed explanation!

This clears up my confusion about Groups vs Profiles.

[Robrecht]

Maybe one small extra question regarding this point:

• You can create three profiles...one for each.  Each profile can point to its own configurations (config.sup, config.pro, customization.ui, library files, etc.).

If I understand it correctly, that means that at the moment you can only read 1 config.pro file per Profile (because each profile only allows one configuration path)

Are there currently any plans so that multiple configuration paths can be read for a Profile?

(This would be very useful for a company with multiple department-specific and global config.pro, customization.ui, ... files)

For example company ACME inc. has a default global config.pro and the Manufacturing Profile has a set of custom config options in their config.pro that override the same config options defined in the global config.pro.

Ideally upon starting Creo+, the global config.pro in the path E:\PTC\CreoPlus\Global would be read and then the config.pro in the location E:\PTC\CreoPlus\Manufacturing

This way the Manufacturing Engineers always have the latest global config options configured by the ACME CAD Administrator.

In case a config option gets deprecated in a future Creo version for example, then the CAD Admin does not have to manually edit all the config.pro's for all the departments and only has to change the global config.pro

[mfischer]

@Robrecht 

Thanks for the additional question.  Let me try to answer.

Today, a profile can only look at one configuration path.  That path or folder, can contain an array of items - config.pro, config.sup, customization.ui, template folders based on the option paths in the config file, etc.  Now you can define your corporate options (standard options) which all users would leverage and have them included in the config.sup in that folder.  The config.sup would read first and applied, then Creo+ would use the config.pro with specific options needed for that given profile.  Obviously, the config.pro will not overwrite those of config.sup and the user would not be able to edit the config.sup options.  I would recommend that you leverage OneDrive for managing the configuration path folders....as it will allow syncing to the end users machine and control file permissions.

However, this might not directly address your question.  You stated that there are global config's....but a profile might overwrite them.  That does not work in a config.sup instance.  As stated config.sup cannot be overwritten by config.pro. 

Most customers I work with...want to have a global or corp config that is not editable by the group or by users.  This is why they leverage just the needed options in the config.sup.  Again it contains just the needed standard config that all users must have.  The config.pro are the ones specific to the group or user.

In the profile setup now, you can leverage the GLOBAL SETTINGS.  This is a default setting that can be applied to all profiles...which again includes the configuration path, language and update timeframe.  When creating a profile, you can use the global settings or define your own.  When defining you own you can change the profile language and configuration path.  Alternatively, you can use the global setting and use the override button, which will allow you to choose a different configuration path (while maintaining language and update timeframe).  When adding the new configuration path it overrides the configuration path defined in the global settings.  One thing we can consider in the future is continue to leverage the global setting config files (.sup, .pro) and append to them the config files in the designated folder when overridden is used.  This way, you can support the use case you asked about.  This is just a thought.....and would need to flushed out further.

You mentioned editing each config file for each configuration path.  Using OneDrive might make this a little easier...as any change in OneDrive will be automatically sync'd to the end users.  Today, you would have to edit each config file in each configuration profile folder, but hopefully that can be easily done by properly managing the structure of the config.

Thanks,

mark