It is essential to apply timing constraints to your multibit clock domain crossing, if this bus has a set_false_path constraint then the skew across the bus can be more than 1 clock period which can cause functional errors.
The first requirement is that you do not have a set_false_path constraint between the two clock domains, if you don't want paths between them to be analyzed for setup and hold then you can use set_clock_groups which has a lower precedence.
Next, constrain the paths with set_net_delay to make them as short as possible and with set_max_skew. Set_max_skew does not constrain the fitter but you can analyse against this constraint in the Timing Analyzer.
The constraints for a clock domain crossing between data_a in clock domain clk_a and data_b in clock domain clk_b might look like this.
create_clock -name clk_a -period 4.000 [get_ports {clk_a}]
create_clock -name clk_b -period 4.500 [get_ports {clk_b}]
set_clock_groups -asynchronous -group [get_clocks {clk_a}] -group [get_clocks {clk_b}]
set_net_delay -from [get_registers {data_a[*]}] -to [get_registers {data_b[*]}] -max -get_value_from_clock_period dst_clock_period -value_multiplier 0.8
set_max_skew -from [get_keepers {data_a[*]}] -to [get_keepers {data_b[*]}] -get_skew_value_from_clock_period min_clock_period -skew_value_multiplier 0.8
The actual skew requirements will depend on your design and how you have handled the clock domain crossing.
Finally, check the timing of your clock domain crossing by running Report Max Skew Summary and Report Net Delay Summary in the Timing Analyzer.