Why Appian allows name duplicacy in Process Model

I am working on Appian 17.3 and I am aware that Appian does not allow users to create duplicate name Expression rules, interfaces , constants etc.

But why Appian allows  same name (Name duplicacy) for more than 1 Process Models.

  • If we have more than 1 Process models having same name, it will cause inconsistency and complexity for developers while adding Existing Process Models in Applications.

I have created 2 Process Models having same name and Appian is allowing me to do it.

Any Suggestions Appreciated

  Discussion posts and replies are publicly visible

  • Hi Prateek Bhati (prateekb) ,
    Its a good shout but I am not completely agree with you on complexity & inconsistency. We can have multiple Processes with same name for different reasons & Scenarios.
    I can say Related Action is the best example for this. In multiple records we can have related action with same name(It will take Process Model name as related action name).
    Anyways, In process model we have description field to mention the Purpose of the Process Model and you can also mention the different or unique Display name as well.

    Hope this will help you.

    Thanks,
    Sandeep
  • Dear Prateek,

    Process Models have Model ID and Model UUID which is unique, you cannot duplicate. So uniquely identified by UUID.
    Your query is obvious but Appian allows the same name because of following reasons (I assume):
    Process model name is for developer view purpose and editable any time. As this is similar to description, no meaning to stop duplicate name, If name gets duplicate, you can easily identified from properties .
    Also, Process display name may configure dynamically, so cannot restrict duplicate values.

    This is ambiguous sometimes but we can accept this as Appian limitation till current version. Thanks
  • +1
    Certified Lead Developer
    Hi @Prateek adding to above participants comments, also process model name doesn't adds any values to the developer, but yes this adds the value to the end user , specially when you want to expose these processes as Related Action.

    Also, an another use case: let's say you want to trigger a process asynchronously in the context of process model instead of API or interface, you need to go for UUID but not process model name, because internally Appian always delas with UUID instead of name.

    I understand that when you have multiple objects with the same name, it's difficult to identify, however still you can identify your process based on its folder hierarchy which will be shown when it's getting populate in picker, let's say while creating a constant of type process model.

    Hence I don't think, if we don't have process model unique name, will make any difference to the end-user.

    Hope this will help you.
  • Interesting topic. I have encountered this use case as well. We needed to have multiple process models with the same name to expose to users as related actions. It does make identifying the correct process model trickier when adding it to an application.
  • I have been in a situation where it was necessary to have process models with the same name because related actions can only have the direct text from the process model name. One way we found that made it possible to tell a difference was by adding a "." to the end of one of the names and ensuring the team knew what the difference was between the two models.

    The UUIDs are different but that doesn't help when making a change from /design to one or both of the models.