An UML sequence diagram shows an example sequence of events/calls that happen for an interaction of a single actor with the system.
If you have multiple interactions with the system that can happen in various orders, but they don't directly affect each other (for the processing of input 1 it doesn't matter if input 2 is also being processed at the same time), then you would draw separate sequence diagrams for each interaction.
If the processing does depend on which inputs are active at the same time, then you can
- try to draw the possible combinations in one diagram
- create separate diagrams for each combination, especially if the order of activation is also relevant
- come to the conclusion that sequence diagrams are not the right tool for this case.