Solution
When you have a top-level VI with normal subVI calls on its diagram and you build it into an executable, all the subVIs are automatically pulled into de the executable because they are statically linked to the top-level VI, by virtue of just being regular subVI calls on its diagram. This workflow usually brings the best experience and causes no issues.
You can also call VIs dynamically, like with Call By Reference for example. Any dynamically called subVIs need to be added as Always Included in the build specification of the executable. This is usually done by adding a folder of dynamically called VIs to Always Included to avoid managing the files individually.
Note: when adding VIs to Always Included, the hierarchy of those VIs, i.e. their static subVI calls should automatically be pulled into the build.
There are also considerations when Dynamic Link Libraries (DLLs) are included. LabVIEW Application Builder checks your code for DLL dependencies and pulls in those DLLs to the build specification. However, it does not recurse DLL calls, so, if you have a VI that calls top.dll, then that DLL will be pulled into the build. But if the top.dll references sub.dll, LabVIEW will not automatically pull sub.dll into the build, and this can cause VIs to be broken when loaded in the executable and sub.dll isn't able to be found by the executable. When you are using DLLs or Packed Project Libraries (PPLs) that your LabVIEW code depends on, you should always install them in the same place for all the machines, something like C:\MyDLLs, that way the code will always look for them in the same place and you will avoid any missing dependencies issue by deploying them in that unique location.