Partially allocated team members

Scrum does not forbid this; but obviously it will cost you productivity and probably satisfaction of your developers.
Scrum is there to make things transparent. So the first thing to do is to make the impediment transparent: If you have a chance, compare your team velocity when allocating people full-time to your velocity when people are on it only part-time. You will probably notice that for each additional project the people are working on at the same time you will lose about 20% in productivity.
If you do not have a chance to try this, try to quantify your impediment in $ (because that is the language management understands). Try to measure the time your team is losing due to task switching - for example by asking your developers to give an estimate on that. Once you have some numbers, make the issue transparent to your management.

As to the situation itself: There is no "golden rule". Every team is different as is every project. So gather your team and let them figure out what to do about the situation. They most likely will come up with several ideas, some of which might be quite creative. Leave the decision with your team.

As soon as daily standup has finished, spend a few more moments on inspect and adapt session in front of Scrum board. Ask Socratic questions on how things were finished and how the team view this. This information leveling will reach everyone including the part time team member. There are few things that emerge from daily standup including impediment list. As you expose everything in transparency, it is up to the part time team member to inspect and adapt, also to act in interest. There is a lot unspoken here and it depends on your context.

There's probably a reason why that team member is part time. Watch out! I smell management interference.

However, it is possible resource is scarce and this team member is shared (as agreed across multiple teams) across integration team and specialists needs.

There are different reasons for having partially allocated resources, and these each have different problems and/or solutions.

Some projects are not bit enough to have a full scrum team, there are two options, use partially allocated resources or dont use scrum. or maybe reshape the project so that it can fill a whole team but this is often not possible.

Some resources bring specialist skills and are not needed full time on a project. For example a security specialist or systems administrator might be required for only a few hours a week. These can be treated as part time members or as an external resource the project uses. Neither is perfect.

Some people actually work part time, perhaps because they have children.

And Im sure other reasons...

If the team members are all split across the same projects, then you can combine all work into one backlog. This situation often happens with BAU maintenance and support, where there just isn't enough work to justify having a team dedicated to one application area.

If it is more scattered than that, with some team members being part time and on miscellaneous projects, the first thing to do is to make it transparent and see if there's a problem or not. Non-dedicated resources are rarely split evenly, their allocation tends to be on-demand and very lumpy, which creates an uneven burn. There is also the headache of knowing which project to bill for...the budget holders are likely to start tracking every penny if they know a developer isn't full time on "their" project.

Also, as Dominik says, there is task switching to be taken into account. As a rough guide, based on my experience, it takes between 30 minutes and an hour for a developer to switch from one task to another and it is usually not viable to split them between more than two projects. A developer split three ways is rarely productive at all.