Parameters Service - 'Management'

[mike_engel]

How, who, and what are your needs in support of Parameters Definitions for your Design Project?
Currently, the parameter service allows the Account Administrator to access the parameters service and perform management tasks from within the Autodesk Construction Cloud web interface.   Help us understand your workflows and requirements in the comments below.  Is your Account Admin the right person to manage parameters, if not who is this person?  What permissions, roles, and enablements would help you in managing the parameters of your account?

[mike_engel]

How, who, and what are your needs in support of Parameters Definitions for your Design Project?
Currently, the parameter service allows the Account Administrator to access the parameters service and perform management tasks from within the Autodesk Construction Cloud web interface.   Help us understand your workflows and requirements in the comments below.  Is your Account Admin the right person to manage parameters, if not who is this person?  What permissions, roles, and enablements would help you in managing the parameters of your account?

[smichaudN26PG]

Default Access should be for BIM and VDC Roles along with Account Admin. (Account Admin should be able to turn on/off BIM/VDC Default Access Levels) For each Project Level a Account/BIM Manager should be able to grant higher Access to the Gen User List but the ability to Add a parameter if granted to a general User Should act like say an Issue where it send a notification to the BIM or Account Manager for Approval, commenting, tweaking etc....

A workflow for Management that would help is to be able to map a Shared Parameters, Project Parameters in an active ACC project to be mapped to the Service Hosted Parameter Collections, with Values copied and a choice to remove the mapped parameter sources.  

We are currently consolidating Shared Parameters and have project that have several "ACCESSORIES" parameters due to low owner ship over Shared Parameters at one point in our Org. This could be useful. 

Another Workflow Idea, (if forge and others ACC abilities get further) would be to have this Bulk add parameter feature help push parameters in to projects as the load to ACC (or start in ACC from a Forge Tool). 

[smichaudN26PG]

Default Access should be for BIM and VDC Roles along with Account Admin. (Account Admin should be able to turn on/off BIM/VDC Default Access Levels) For each Project Level a Account/BIM Manager should be able to grant higher Access to the Gen User List but the ability to Add a parameter if granted to a general User Should act like say an Issue where it send a notification to the BIM or Account Manager for Approval, commenting, tweaking etc....

A workflow for Management that would help is to be able to map a Shared Parameters, Project Parameters in an active ACC project to be mapped to the Service Hosted Parameter Collections, with Values copied and a choice to remove the mapped parameter sources.  

We are currently consolidating Shared Parameters and have project that have several "ACCESSORIES" parameters due to low owner ship over Shared Parameters at one point in our Org. This could be useful. 

Another Workflow Idea, (if forge and others ACC abilities get further) would be to have this Bulk add parameter feature help push parameters in to projects as the load to ACC (or start in ACC from a Forge Tool). 

[Jason_Peckovitch]

Here are my thoughts - For Management, I don't necessarily want all of our 40+ admins to have access to edit these parameters. Our current text file is on network drive that myself and my partner are the only ones that can modify it. Using this service opens up to 40 people who mostly do not understand parameters and creating them to now be able to do that. 

[Jason_Peckovitch]

Here are my thoughts - For Management, I don't necessarily want all of our 40+ admins to have access to edit these parameters. Our current text file is on network drive that myself and my partner are the only ones that can modify it. Using this service opens up to 40 people who mostly do not understand parameters and creating them to now be able to do that. 

[Chad-Smith]

There are various levels of permissions that need to be attached to the Parameters Service, and I feel it should be mostly driven using the Collections rather than individual parameters.

• Account Admins should control what is an approved Collection/Parameter in that account.
• Collections should not be available to projects unless authorised for use, as some Collections might be defined for specific clients and have no right to be used in other client projects.
• I'm currently in two minds whether it should be the Account Admin or Project Admin who authorises a Collection's use in a project. I'm leaning towards the Project Admin.
• When a Collection is authorised for project use, that Project's Admin should have some mechanism to add new Parameters to the Collection. I'm imagining a scenario whereby a Collection is synced from the Account down to the Project. It could be that the original Parameters in this Collection are 'locked' as they are sourced from the Account, but they coexist with any new project-specific Parameters.
• The Project Admin should have a mechanism to request a new Parameter be added into the Account Admin for future use.

I would also like to see the Parameter Service be Bridged across Accounts.

• As the GC, we will increasingly need to adopt an Owner's asset parameter requirements. They are currently providing us with their Shared Parameter file.
• If the Owner is an active ACC user with their own account, then they should be the one's who are hosting the Parameters.
• When they Bridge their Collection to us:
  • They do so directly into the our Project, thereby bypassing our Account Library.
  • We as the receiver would still validate the incoming Collection, and approve the Bridged connection.
  • As a Bridged Collection, in this instance the Project Admin should not be able to add to the Collection. Any changes or additions should go back to the Collection's owner (e.g. the building Owner) to approve.

[Chad-Smith]

There are various levels of permissions that need to be attached to the Parameters Service, and I feel it should be mostly driven using the Collections rather than individual parameters.

• Account Admins should control what is an approved Collection/Parameter in that account.
• Collections should not be available to projects unless authorised for use, as some Collections might be defined for specific clients and have no right to be used in other client projects.
• I'm currently in two minds whether it should be the Account Admin or Project Admin who authorises a Collection's use in a project. I'm leaning towards the Project Admin.
• When a Collection is authorised for project use, that Project's Admin should have some mechanism to add new Parameters to the Collection. I'm imagining a scenario whereby a Collection is synced from the Account down to the Project. It could be that the original Parameters in this Collection are 'locked' as they are sourced from the Account, but they coexist with any new project-specific Parameters.
• The Project Admin should have a mechanism to request a new Parameter be added into the Account Admin for future use.

I would also like to see the Parameter Service be Bridged across Accounts.

• As the GC, we will increasingly need to adopt an Owner's asset parameter requirements. They are currently providing us with their Shared Parameter file.
• If the Owner is an active ACC user with their own account, then they should be the one's who are hosting the Parameters.
• When they Bridge their Collection to us:
  • They do so directly into the our Project, thereby bypassing our Account Library.
  • We as the receiver would still validate the incoming Collection, and approve the Bridged connection.
  • As a Bridged Collection, in this instance the Project Admin should not be able to add to the Collection. Any changes or additions should go back to the Collection's owner (e.g. the building Owner) to approve.

[aaron_rumple]

I need ADSK to just make more and more built-in parameters, so we all talk the same language. Parameters are the "Tower of Bable" that will eventually kill Revit. Akin to the mess of AutoCAD layers that became a nightmare.

Door Glazing?
Door Hardware?
Frame Material?
Frame finish? (Don't get me started on finish and materials...)
Door threshold?

[aaron_rumple]

I need ADSK to just make more and more built-in parameters, so we all talk the same language. Parameters are the "Tower of Bable" that will eventually kill Revit. Akin to the mess of AutoCAD layers that became a nightmare.

Door Glazing?
Door Hardware?
Frame Material?
Frame finish? (Don't get me started on finish and materials...)
Door threshold?

[RobDraw]

---

@aaron_rumple wrote:
I need ADSK to just make more and more built-in parameters, so we all talk the same language. Parameters are the "Tower of Bable" that will eventually kill Revit. Akin to the mess of AutoCAD layers that became a nightmare.

Door Glazing?
Door Hardware?
Frame Material?
Frame finish? (Don't get me started on finish and materials...)
Door threshold?

---

It's a good thing you came along. These things need to incorporated into the parameters service right away or we all die a slow death.

[RobDraw]

---

@aaron_rumple wrote:
I need ADSK to just make more and more built-in parameters, so we all talk the same language. Parameters are the "Tower of Bable" that will eventually kill Revit. Akin to the mess of AutoCAD layers that became a nightmare.

Door Glazing?
Door Hardware?
Frame Material?
Frame finish? (Don't get me started on finish and materials...)
Door threshold?

---

It's a good thing you came along. These things need to incorporated into the parameters service right away or we all die a slow death.

[aaron_rumple]

Nothing new. I've been talking about this since the days of the Zoogdesign Revit Forum.

[aaron_rumple]

Nothing new. I've been talking about this since the days of the Zoogdesign Revit Forum.

[RobDraw]

Sorry, I thought the sarcasm was very clear in my post.

[RobDraw]

Sorry, I thought the sarcasm was very clear in my post.

[aaron_rumple]

Parameter Services hasn't fixed anything.

[aaron_rumple]

Parameter Services hasn't fixed anything.

[tnievesP53K8]

1 - I think Parameter service access should be separate from admins. should have it's own access that can be added to any individual, position, etc.

2 - Since revit uses GUID's, there doesn't seem to be any reason we can't edit names once a parameter is put in. There are a number of reasons this may want to happen, but what we don't want is to break all our families by making fresh new parameters. If there are issues with this in families despite the GUID, then this service should solve that otherwise it's not much different than just a shared parameter. Additionally making the switch from project parameters to shared parameters for all standard parameters isn't as feasible if the name cannot be edited.

3 - Not sure whether this is temporary or permanent, but you cannot add any shared parameters you have already added with the same GUID. This becomes an issue (especially if just testing) if you archive a set of parameters, then go and try to re-import them. Maybe add a warning and even a list of which parameters already exist and see both versions, but to not be able to re-upload just confirms this service isn't ready yet. (even if it takes time, it's currently been 30 minutes and I still can't re-upload my shared parameter file.) another solution would be to allow access on ACC to permanently delete archived parameters

4 - It would be nice if the service could manage parameters in a way that they can "Sync" changes but only if activated. This way if something changes in the cloud it can be adjusted in a project IF we choose to sync.

The real benefit of having a cloud service needs to be ease of all parameter management, being able to easily find parameters, edit them, and have them, and have collections that can be accessed. Additionally, these collections should be one click loadable to a project. This could be done simply by have a check all checkbox above all the checkboxes.

[tnievesP53K8]

1 - I think Parameter service access should be separate from admins. should have it's own access that can be added to any individual, position, etc.

2 - Since revit uses GUID's, there doesn't seem to be any reason we can't edit names once a parameter is put in. There are a number of reasons this may want to happen, but what we don't want is to break all our families by making fresh new parameters. If there are issues with this in families despite the GUID, then this service should solve that otherwise it's not much different than just a shared parameter. Additionally making the switch from project parameters to shared parameters for all standard parameters isn't as feasible if the name cannot be edited.

3 - Not sure whether this is temporary or permanent, but you cannot add any shared parameters you have already added with the same GUID. This becomes an issue (especially if just testing) if you archive a set of parameters, then go and try to re-import them. Maybe add a warning and even a list of which parameters already exist and see both versions, but to not be able to re-upload just confirms this service isn't ready yet. (even if it takes time, it's currently been 30 minutes and I still can't re-upload my shared parameter file.) another solution would be to allow access on ACC to permanently delete archived parameters

4 - It would be nice if the service could manage parameters in a way that they can "Sync" changes but only if activated. This way if something changes in the cloud it can be adjusted in a project IF we choose to sync.

The real benefit of having a cloud service needs to be ease of all parameter management, being able to easily find parameters, edit them, and have them, and have collections that can be accessed. Additionally, these collections should be one click loadable to a project. This could be done simply by have a check all checkbox above all the checkboxes.

[jj5809986]

In order to understand the needs and requirements for managing Parameters Definitions in a Design Project, it is important to consider the workflows and roles involved. The Account Administrator is typically responsible for managing the overall account and its settings, including parameters definitions, but it is possible that there may be other individuals or teams involved in managing the parameters specific to a project.

To ensure the efficient management of parameters, it is important to have clear guidelines and protocols in place for defining and managing parameters. This may involve establishing roles and permissions for different team members, depending on their level of involvement in the project.

For example, the Account Administrator may have full access to all parameters definitions, while project managers and team members may only have access to the parameters specific to their project or task. Additionally, it may be necessary to establish approval workflows or version control mechanisms to ensure that changes to parameters are properly documented and reviewed.

Ultimately, the specific needs and requirements for managing Parameters Definitions will vary depending on the nature of the project and the roles involved. It is important to have a clear understanding of these needs and requirements in order to effectively manage parameters and ensure the success of the project.

[jj5809986]

In order to understand the needs and requirements for managing Parameters Definitions in a Design Project, it is important to consider the workflows and roles involved. The Account Administrator is typically responsible for managing the overall account and its settings, including parameters definitions, but it is possible that there may be other individuals or teams involved in managing the parameters specific to a project.

To ensure the efficient management of parameters, it is important to have clear guidelines and protocols in place for defining and managing parameters. This may involve establishing roles and permissions for different team members, depending on their level of involvement in the project.

For example, the Account Administrator may have full access to all parameters definitions, while project managers and team members may only have access to the parameters specific to their project or task. Additionally, it may be necessary to establish approval workflows or version control mechanisms to ensure that changes to parameters are properly documented and reviewed.

Ultimately, the specific needs and requirements for managing Parameters Definitions will vary depending on the nature of the project and the roles involved. It is important to have a clear understanding of these needs and requirements in order to effectively manage parameters and ensure the success of the project.

[Sahay_R]

Please consider organizations where multiple disciplines are under one roof! In organizations such as ours, the Account Administrator is traditionally from IT. This would add another layer of management for a simple task like adding a new Shared Parameter - which I would be happier and more efficient without.

Additionally - I would not want other disciplines to get access to my discipline's Shared Parameters, as I'm sure the BIM leads in other disciplines won't want me in theirs'. 

Also - I would not want all team members to be able to add / edit these parameters. This privilege should be restricted. Frankly I would restrict this capability only to designated BIM Leads, not the Project Administrator. I would not want to deal with a glut of project specific parameters in the file.

To summarize - permissions to define levels of access. These permissions can be assigned by the Account Administrator so that department BIM Leads can have access to their specific parameter sets and manage them as needed.

[Sahay_R]

Please consider organizations where multiple disciplines are under one roof! In organizations such as ours, the Account Administrator is traditionally from IT. This would add another layer of management for a simple task like adding a new Shared Parameter - which I would be happier and more efficient without.

Additionally - I would not want other disciplines to get access to my discipline's Shared Parameters, as I'm sure the BIM leads in other disciplines won't want me in theirs'. 

Also - I would not want all team members to be able to add / edit these parameters. This privilege should be restricted. Frankly I would restrict this capability only to designated BIM Leads, not the Project Administrator. I would not want to deal with a glut of project specific parameters in the file.

To summarize - permissions to define levels of access. These permissions can be assigned by the Account Administrator so that department BIM Leads can have access to their specific parameter sets and manage them as needed.

[craigjonnson]

As an account administrator, I wouldnt want to manage this for every project or keep requesting from other Hub account admins.

I would prefer to be able to assign these to the Project Admins, or possibly roles to allow 3rd party HUB admins to be able to assign to our Project BIM Managers where they would be uncomfortable assigning trade partners admin rights to their project hubs.

[craigjonnson]

As an account administrator, I wouldnt want to manage this for every project or keep requesting from other Hub account admins.

I would prefer to be able to assign these to the Project Admins, or possibly roles to allow 3rd party HUB admins to be able to assign to our Project BIM Managers where they would be uncomfortable assigning trade partners admin rights to their project hubs.

[tnievesP53K8]

The problem with that approach is that firms already deviate from some built in parameters and the more that happens the more duplicates end up making things more confusing. The problem lies in that some people schedule things differently such as using “type parameters vs instance or vis versa. I think. The parameter service is getting closer but needs the following (and already has a couple I think)

- ability to change names and let revit properly use the GUID for keeping it connected regardless of name.

- ability to change how a parameter is brought in even when there’s a default (type vs instance)

- when deleting a parameter the guid needs to be released.

if the parameters are too rigid in the service and cannot be edited it isn’t something I would want to let project admins manage. It makes it less dangerous something gets broken permanently or named incorrectly.

[tnievesP53K8]

The problem with that approach is that firms already deviate from some built in parameters and the more that happens the more duplicates end up making things more confusing. The problem lies in that some people schedule things differently such as using “type parameters vs instance or vis versa. I think. The parameter service is getting closer but needs the following (and already has a couple I think)

- ability to change names and let revit properly use the GUID for keeping it connected regardless of name.

- ability to change how a parameter is brought in even when there’s a default (type vs instance)

- when deleting a parameter the guid needs to be released.

if the parameters are too rigid in the service and cannot be edited it isn’t something I would want to let project admins manage. It makes it less dangerous something gets broken permanently or named incorrectly.

[BIMologist_]

@mike_engel @Chad-Smith 

Help | Permissions in the Parameters Service | Autodesk

Account Admin: to initiate the service. They can have full control.
Parameter Service Admin: Create and Control Collections. There should be a way to identify which Collections get associated with a new project. (via Project Template)

Collections can be Company, Discipline, Client, etc. based. Assign multiple collections to a Project Template / Project. Only project-associated Collections should be available to Project Admins and Project Members.

Bridging would be great. 

Parameter Service Collections Admin: Various disciplines can each have a collection. 

Project Admins: Should NOT be allowed to upload the parameters from Revit or make any changes. We had one admin upload 1000 parameters to the service. The only solution was to delete ONE parameter at a time. You can guess how painful it was. Please allow BATCH functions on the parameters. 
Why the permissions are not consistent with ACC web. No access, No Access in Revit. 
They can associate a collection with a project, however. 

• Autodesk Construction Cloud: No Access.
• Revit: Access the Parameters Service through Revit to upload shared parameter file or files, upload parameters from the active Revit file, create and edit parameters, labels, bindings, saved searches. Can load parameters into the active Revit model.

Project Member:  Can load SPs into Revit model from Project associated Collections.

[BIMologist_]

@mike_engel @Chad-Smith 

Help | Permissions in the Parameters Service | Autodesk

Account Admin: to initiate the service. They can have full control.
Parameter Service Admin: Create and Control Collections. There should be a way to identify which Collections get associated with a new project. (via Project Template)

Collections can be Company, Discipline, Client, etc. based. Assign multiple collections to a Project Template / Project. Only project-associated Collections should be available to Project Admins and Project Members.

Bridging would be great. 

Parameter Service Collections Admin: Various disciplines can each have a collection. 

Project Admins: Should NOT be allowed to upload the parameters from Revit or make any changes. We had one admin upload 1000 parameters to the service. The only solution was to delete ONE parameter at a time. You can guess how painful it was. Please allow BATCH functions on the parameters. 
Why the permissions are not consistent with ACC web. No access, No Access in Revit. 
They can associate a collection with a project, however. 

• Autodesk Construction Cloud: No Access.
• Revit: Access the Parameters Service through Revit to upload shared parameter file or files, upload parameters from the active Revit file, create and edit parameters, labels, bindings, saved searches. Can load parameters into the active Revit model.

Project Member:  Can load SPs into Revit model from Project associated Collections.