I’d say this depends on the audience. If you’re building a setup only for you and your small team, you can expect a certain workflow, e.g. that they set a specific vendor type, or version a custom property when adding the host. You can make this mandatory, so they and you know about this fact.
When you’re the admin for the Director, and your user base splits up into dedicated teams from different environments in your company (also with fine granular permissions), I would define as much as possible up front. This is to keep the workflow on how to add a new object very tight and clean. Typically, users make errors with free form or listed fields, and then the wrong camera version is deployed.
Instead, when such a thing is documented as pre-defined template (even where they don’t have access to modify), they’ll know that the “imports” is very important for the good behaviour.
One thing you need to keep in mind though - the longer and deeper the template tree goes, the harder it is to maintain over time. Likewise, when you decide to remove a template because that version is EOL, you’ll need to clear up all dependent objects too. This needs a strategy for removing stale entries and dependencies.
At this stage, a specific data field with a more generic template can probably solve the hassle for not having to modify the templates later, or even deleting them.
Plan ahead for the next five years too:
- Are there more different types expected or will they stay the same?
- When working with different teams, will there be more new teams and templates added over time?
- Are you going to automate things later on with e.g. using a CMDB or AD or a different storage?
- If yes, a custom property is easier to set than to match a possible template for this object type
This isn’t just Director specific, I have seen this with other old config tools too (LConf, etc.).