Workspace Naming Best Practices

Hi,

We have over 1/2 a dozen workspaces.  Are there any restrictions to the naming conventions for Workspaces?  I know we'll have environments for Development, Test, UAT, Productions, etc. 

 

What are the best practices for naming Workspace environments?  Are there character limitations?

 

Thanks

Daniel

Tagged:

Answers

  • Hi Daniel,

     

    I'm not aware of any restrictions on the naming convention. However I try to make a link to the business, region and function and the model.

    The company name does not need to be in the workspace, because this is not relevant for a client. 

    Have not worked in an environment yet, where there are different model builders between DEV, TEST and PROD and most of the times we can keep ALM within a workspace. However perhaps I would even put the instance type before the workspace name instead of a suffix. Makes it easier to quickly focus on DEV models or TEST models.. However it does not make a big difference. 

     

    Exampels:

    NL - FINANCE - P&L

    BE - SUPPLY - TRANSPORT

    DEV_BE - SUPPLY - TRANSPORT

    TST_HQ - FINANCE - ZBB

     

    Not sure how others are doing it though.

     

    Regards,

    Eije Wiersema

  • @CommunityMember115525 

     

    There aren't standards, but I would agree with @eije.wiersema in what he stated.  I would think about the type of data that workspace will be housing (Finance, HR, Supply Chain, etc.).  Additionally, if your company operates completely in silos where pieces of the business will never talk to each other, you can name it in correspondence to that "business unit" (Deep Water - Supply Chain, Deep Water Finance, Upstream Supply Chain, etc.).  Also, it is a very good idea to have a prefix of Dev, UAT, Prod as @eije.wiersema  mentioned as well.

     

    Rob

  • Hi @CommunityMember115525 

     

    There is a character limit of 60 characters for model names.

     

    With regards to conventions, I agree with everything previously said. The name chosen should provide enough information to the user that they are accessing the right model.

     

    I have also recently heard of some interesting model names (Storm) being used for a forecasting and planning model - as long as a name is chosen early and training and documentation covers this, I see no reason why not!