I think your issue is not really about bubble or dropsource per se but more of how you create your data structure.
If you don’t design a good data structure for your application requirements and business logic, it’s going to be extremely difficult to be able to implement it in bubble or dropsource.
I’m not sure i’m following your data setup above. Why is Creator Company Name of User type?
Anyway from the little i can get from your explanation you simply want to associate some object with some users.
I’m not sure what the specifics are whether it is a one-to-one, one-to-many or many-to-many.
I’m going to assume a one-to-many since you used SMS as an example. That is a user can send a message to a list of other users who are a subset of the users whole contacts.
So lets assume that a Request can be sent by a User and it can be received by a list of Users, this is how you should set up your data.
In your Request Thing (or Table), you need a to have a field say Recipients which is a list of Users. Every Table created in bubble has by default the Creator field which is a user. So here the Creator of the Request this is the sender and the Recipients (list of User) are the only people who will receive the request.
Lets assume you know how you will create a new Request and so you have some data in your Request table like below
Creator | Request Id | Request Type | Recipients
User 1 | 1 | req. type1 | User2, User5,User4
User 2 | 2 | req type3 | User1
User 1 | 3 | req type3 | User3, User5
So now assuming User5 goes to his request page, he’s supposed to be shown request id 1 and 3. User1 should see request 2, User3 should see request 3 also, etc.
As i stated earlier all these are not really a bubble or dropsource issue. It’s how you setup your data structure based on your application requirements and business logic.
So now let’s look at how we will be able to filter the request data so that each user sees his intended requests.
Lets use User5 as an example. To be able to find requests that he’s a recipient of, we need to search the Request table, and for each row, we search in the Recipients field, and if that list contains User5 we include it in our result.
So in bubble you will do a
Do a Search for Request then you add the constraint
Recipients contains Current User
This will return rows 1 and 5 since User5 is in the Recipients list of these two rows.
So basically this will be the action (Return data from api action) you will define in a bubble workflow endpoint called say getrequest with a parameter say userid (which is the userid of the current user) and the workflow will return data which is the result of your search.
Then in dropsource its simply a matter of calling this endpoint
wf/getrequests then in the body of the request you supply the current user id. You can get the current user idea from the login worflow, it returns the token, expiry and userid.
Like i stated in my earlier posts you can do all the heavy searching and filtering in bubbles end. So in this case all you need to send from dropsource to bubble is the userid to an endpoint in bubble which will return the filtered data.
Hope this helps.