Blocking the creation of Definition Copies for certain Object Types

The usual way is to have semantic checks. There is a rule available that can check that your roles and ASTs also have an occurrence in a library model type.

Make the successful execution of your semantic check profile a prerequisite for submitting the process model for approval. Regularly perform the reorganization of the database, so the debris of objects created that way get's cleaned up by itself.

Some customers also implement workflows for submitting new roles/ASTs for approval that were invented/discovered by a process modeller. After approval of the object and integration into the library by the library owner the process modeller would be allowed to submit his process.

Yeah, we also do the semantic check thing to make sure only library items are used. But this is a reactive exercise and I want to be proactive.

What do you think about creating a macro which is triggered every time an app or role is supposed to be copy/pasted??? Can be heavy as it has to go through the library every time to look for the master object.

I agree to Peter regarding proactive/reactive. Usage and maintenance of the repository is a punishment for the administration (preserving a clean, consistant repository). There is only one help to lock elements so that they cannot be changed. 

@M. Zschuckelt/SAG: Please invest a little bit more of your software development team in improving the existing functionality (and not only in sexy things like AI driven modeling). In "ARIS share your ideas" you have 437 requests in the category "modeling and contribution" open for voting, only 6 are planned. 36 were realized more than 2 years ago (besides one 5 months ago). There are also some regarding the improvement of the repository. MODELING-I-23 I think would solve Peters request.

Regards

Klemens

I just voted for the suggested request. Unfortunately it's not "my" software development team.

We decided to go for a macro which pops up in case people are using a non-library object. But instead of scanning e.g. the whole app library (>3600 objects) we just check whether the used object is from the library path. This should be very fast...

Thanks for the hint, that's what I like about this forum:

we just check whether the used object is from the library path. This should be very fast...

Regards, Martin