I recently had to make the same decision with the current project that I'm working on. Basically, there was a use case for a rep with limited permissions and a use case for an admin with all permissions to create, edit, etc. My situation may be a little bit different than yours due to certain feature sets within the app, however in my case, most features that were available to the rep were also available to the system admin, but they obviously had more features at their disposal.
Given that both users will have different accounts, the system admin can define and allocate permissions which in turn, removes/adds features accordingly. So depending on whether you're a normal rep or a sysadmin, you'll either have a limited amount of features available to you or everything.
Now, does this affect the UI and the decisions that you make with it? Absolutely. If you want to create an experience that is familiar across all users regardless of permissions, if that's the way you want to go, then how you design the interface is important. The approach I did was segmented most features into their own blocks per se. This means being cognizant of what features rely on what, however if done right you can still make the experience similar with or without a certain feature for both parties.
In the end, it really depends on the particular use cases. Fortunately in my case, having it so there's a limited feature set for one party through permission and little more available for the other (and not being superfluous at the same time)it creates a consistent experience for both users and is less time to market with having only to build one product.