Hi @penny_christens , I think @JamesSekcienski is on the right track.
If you can persuade your developers to work with it, I really don't see a clear reason why a Canvas side crosslisting process is necessary. You are able to use SIS or API, or even manual import to bring students into a common course shell whilst allocating them to do this for different sections (we do this to create marker groups in very large courses).
Usually crosslitsing as Canvas presents it is needed because we have students with different characteristics who sit in the same classroom ? online course for efficiency. This can include full time / part time, accredited /non accredited etc.
The important aspect that crosslisting delivers is to preserve the distinction to allow separation of start / end dates, activities, assignment and comms, and rosters.
The Canvas approach is a downstream solution that could be dealt with in the SIS or middleware by "co-listing" rather than crosslisting, avoiding the messy zzz redundant shells. Students would simply be provisioned direct using an appropriate section name (probably corresponding to your SIS).
all this requires is an intermediate table within the SIS provisioning interface where the relationships between modules and sections are set up in advance enabling the provisioner to go row by row determining whether each SIS entity/section required to be in a standalone course shell or a combined course shell ..... if that makes sense....
Crosslisting in its original form is most useful in the first couple of years of LMS implementation where the SIS doesn't really reflect the complexities of which students are being co taught - after a couple of iterations this should be bedded down and managed via the SIS / SIS interface ....
