Another option could be to create a separate section into your job configuration, specifically to enter one or multiple decoding profiles. That allows the end user who is entering the job information to decide whether none, one or even multiple decoding instances should be added to this job.

The configuration of how a job needs to look like is extremely flexible and allows you to add any field. Moreover, a specific section can be configured to allow multiple instances.

The result for the end user adding the job is following, allowing them to choose the number of decoding instances to a single job:

Note that previous comments made by Steven is indeed best practice, as it guides the users entering the job to more easily just select one of the allowed profiles. This information is translated to actual values when the job is (automatically) converted to a booking.

I'll leave it up to the technical experts to get back to you Bruno on this one, but I wanted to take the opportunity to highlight some important design principles and best practices related to the design of SRM solutions, which involve jobs and bookings.   The many features & capabilities of the involved software modules can be used in many different ways, but the quality of the overall SRM implementation very much depends also on how well it is aligned with the design principles.  And when I say quality of the SRM implementation, I mainly refer to the user experience.

To put it very simple: a JOB is aimed at being an expression of a NEED, something that somebody wants, and it should be kept as simple as reasonably possible, and it should expose as little technicalities about the service that will eventually fulfil the need as possible.  The BOOKING that results from a JOB that was entered into the system is really the actual deliverable you could say to satisfy the need expressed in the JOB (note: one job could in some solutions also result in multiple bookings).  The booking defines what kind of service will be rolled out (service definition), which resources are going to be used for that (taking into account their availability and capabilities), and the profiles that need to be loaded.  A job can be translated into a booking automatically, or sometimes there is a human operator involved.  The latter can be for two reasons.  A) the job does not have enough information overall to automatically translate it into a booking, and a human needs to be involved to make further decisions about potentially which service will be booked for that job and/or which profiles will be applied for example.   B) maybe it would be perfectly possible to translate a job into a booking automatically (i.e. it does contain all the information needed to do that), but the user prefers a human to check / to approve.

Not to say that there cannot be any exception, but in a job you ideally don't care about resources, and you definitely would not pick specific resources.  The person that creates a job does not care about that, he has a need and wants to express that need.  How that need is satisfied (i.e. how the job is translated into a booking) is up to DataMiner (potentially assisted by a technical operator - but I would say that the latter should be avoided unless that's explicitly needed and required, after all this is about orchestration and reducing the need for humans to be involved in unnecessary tasks).

I kind of like to compare this sometimes to getting a rental car or a hotel room online.  I will express a need, such as the category of car or hotel room that I want and when I want it.  I will never find a website that will give me all the actual rooms or cars that fall within the category that I specified.  The underlying booking system will allocate a resource to me that will satisfy my need (and it will do that taking into consideration all the other needs from other jobs, and it will try to make sure that all available resources are used in the most optimal way - e.g. for two jobs within the same category, the booking system might opt to give the slightly newer car to the gold member as compared to the non-gold member).  Or to put it in a simple technical case, if I have a job for an SD downlink, and I have two IRDs available (one SD-only and one SD/HD so to speak), it is smarter to take the SD-only resource (so that it still is possible to accept a job for an HD booking).

Jobs should be kept as simple as possible, jobs should avoid too many technical terms, jobs should avoid exposing resource selections.  Of course, inevitably when you specify a job, you will be selecting automatically a specific resource (e.g. in a SDMN network, if you select a specific source, you inevitably select a specific resource, because that's the only entry point into the network). But even in that case you should try to make a user-friendly selection (i.e. use a user friendly name of label, and not a request to select a resource).

Again, these are just design principles.  And there are good reasons sometimes why they are not applicable, and we need to deviate from them.  But they are the default approach, and deviations should be based on a reasonable motivation.

On a last note: many users are very used to being able to select the resources themselves, simply because in the past this was the only way of working.  So sometimes this is also about mindset.  But considering the evolution of technology (ALL-IP, virtualization, cloud services, etc.), and the dynamics & complexity that comes with it, resource selection and allocation really needs to be taken care of as much as possible by the orchestration software, and manual selection of resources really needs to be limited to the absolute strict minimum, i.e. only where it is absolutely needed.

And note also that a good design makes maximum use of profiles as well (rather than having users enter individual settings).  But that is a whole other discussion again, and again it is about principles and nothing is carved in stone (i.e. the practical use case still defines what the best solution is).

I'm not familiar with your application, so I do not know to what extent this applies, but I just wanted to take the opportunity to share this in case it would be of interest.