Capabilities are weird. They do work, though. Generally, a capability allows you to break the resource group/resource relationship on an operation when a resource is overloaded.
You have to remove the resource group AND resource callout, and add the capability. Then, the capability has to specify the resources (and you select the order in which they will be loaded). It is important to specify all of the resources that the part can run on, as the operator will only be allowed to specify the resources contained in the capability when clocking. (We learned that the hard way).
What I generally do is specify the alternates as the first possible choice (oddly enough, that means it will have the “highest priority number”). Then, I list the original resource as the “lowest priority number”. I’ve snipped one below for illustration.
In an infinite environment, I have no idea how the system selects the resource from the capability. (we run full finite here). I suspect it will take the “highest priority number” resource, as that seems to be normal operation of the scheduling engine.
Machine 14 is in a different resource group than machines 55 and 78. The way this will work is the system will look for time on machine 55 first, machine 78 second, and lastly Machine 14.
A lot of shops use resource groups to combine machines with similar capabilities, that is a very common business practice. This feature allows you to work around that when you have an item with unusual characteristics - in that the capabilities of the equipment are NOT common for the part/op you are examining. (Think of a lathe that operates with a certain specification. You may have three large lathes in a group, and three small lathes in another group. But, only one of the lathes in each group has the specification the item requires, and the part can run on either large or small, but needs this specification). Instead of having to reconstruct the resource groups, you just create a capability for the part/op.