To @Bryce's point above, is there a best practice that should be followed when needing to modify a SS2 service using the SCA developer tools? When modifying SS1 backend models and service controllers, we could simply spin up a new module, require the module that we were looking to extend and then add our new logic via _.wrap or _.extend. We could then include this new module to our distro and have it compiled within the ssp_libraries.js file. Since all of the backend modules were included in the same file, if the module that we extended were to be executed, it would also execute our extended logic. The challenge with SS2 files is that each module is separated out into its own directory. For example, the transaction history module has a directory, with a service, service controller and handler. If there were some logic within the handler that needed to be extended, there does not seem to be a way to do this without either making a direct modification to the source file, or by creating a whole new custom transaction history module, with its own service, service controller and handler, and essentially importing the transaction history handler and extending it with the new logic. You would then need to replace the frontend transaction history collection URL with the new custom transaction history service URL. I have been able to make the latter work, but I'm curious if there is a different, more preferred method for achieving these results.