Naming Convention : tips

michel_maurel
michel_maurel
in Modeling

Hi, anyone should read an apply the Naming conventions which are described in Anapedia.  I found it usefull to add some personnal ideas. When you build a model, you will often find duplicate names for :

  • module (Sales Plan)
  • dashboard (Sales Plan)
  • action open dashboard (Sales plan)

Of course Anaplan will prevent using the same name in duplicates, and your entry will be rejected, but when the model starts to be huge, it will take some seconds or dozen of seconds or even more than one minute before you get the hand back, waiting for your mistake to be solved. To avoid this, I usually build my model by the following conventions, in combination with Anapedia's good practices :

  • module : Sales Plan Calc or Sales Plan Entry but NEVER DATA ENtry which i reserved for dashboard.
  • dashboard : Sales Plan or Sale Plan Data Entry. I use a name (substantive /noun)
  • action to open dahsboard : Enter Sales Plan. I use a verb because it's an action.

Of course I do it in french because most of my models are in french. The example I wrote here are only for illustration purposes. The idea is to find a recurring pattern which can be applied and remembered by the model builders and which fit Anapedia's practice. My pattern is : Module : process description. Dashboard : Name Action Open dashboard : Verb Eager to hear abour your own practices. Kind regards. Michel.

Tagged:

Answers

  • peter_mcanena
    peter_mcanena
    I use the following naming conventions for my actions:
    • IMPORT LIST: Description
    • IMPORT SUBSET: Description
    • IMPORT MODULE: Description
    • CLEAR MODULE: Description
    • DELETE LIST: Description
    • EXPORT MODULE: Description
    The Description part can be either a brief description (e.g. IMPORT LIST: Insert New Customers) or just the name of the list/module affected (e.g. IMPORT LIST: Customer).

    The only difference between IMPORT MODULE and CLEAR MODULE is that I use CLEAR when it's an import specifically designed to clear out the data (i.e. importing zeroes, blanks etc.) and the only difference between IMPORT LIST and IMPORT SUBSET is that I use SUBSTE when it's an import that doesn't add or edit any items but just updates the membership of the list's subsets.

    For the import actions I think it's really important to have a distinctive prefix so that you can tell the difference between the actions you've created for long-term use and one-off imports that Anaplan has saved (which you may want to delete eventually).
  • michel_maurel
    michel_maurel
    Hi Peter,
    thanks for thi additionnal list.

    Very interesting to make distinctions such as IMPORT SUBSET vs IPORT LISTS ou CLEAR vs IMPORT.

    I will use this from now on and make my customer use them as well. Thus we will have a community of anaplanner using the sae patterns all over he world...
     
    Kind regards.
    Michel.
  • YS_*12825
    YS_*12825

    I have an issue with this tip:

    Any isolated import or export actions can be added to an All Action process. This process will never be run but prevents accidental deletion of actions that aren’t part of a process.

     

    It is inefficient. You can't see when one of your actions becomes obsolete. You have a process that never runs.

     

    Instead I never publish actions to dashboards, only processes. So any isolated action is added to it's own process (with one single action assigned to it), and then the process is published to dashboard. This solution has the same benefit as the one above - actions will not be deleted accidentally, and it has added benefit of being able to choose user-friendly name for the process. And it is easier to understand if it is still relevant and where exactly it is being used.

     

    Hope it helps someone 🙂

  • DavidSmith
    DavidSmith

    @YS

     

    Thanks for you input. and yes best practice is not to publish actions to dashboards

    Where an Action is to be run by a user, the Process it is part of — not the Action — should be published to the dashboard as a button with a friendly name

    When this article was written we didn't have the same visiblity of the 'referenced by' so the tip was useful to prevent accidental deletion (you couldn't tell if the action was used or not).

    However, now that we have the following it is a lot easier to see if an action is obsolete2018-09-05_17-15-05.png

     

     

  • YS_*12825
    YS_*12825

    When this article was written we didn't have the same visiblity of the 'referenced by' so the tip was useful to prevent accidental deletion (you couldn't tell if the action was used or not).

     

    This is a good point. Anaplan functionality evolves quickly, so best practices should keep up with it. I think this topic's goal is to help with keeping up 🙂

Categories