I'm using a Job ID that carries across the entire databse,
That might be the problem since you need an artists ID in some of your relationships in order to submit them for a particular job.
And since you can submit multiple artists to a given job and a given artist can be submitted to multiple jobs, this is not a simple one to many or many to one relationship, it's a many to many relationship.
Jobs::__pkJobID = Submissions::_fkJobID
Artists::__pkArtistID = Submissions::_fkArtistID
You can place a portal to Submissions on the Jobs layout to list and select Artists records for each given Jobs record. Fields from Artists can be included in the Portal to show additional info about each selected Artists record and the _fkArtistID field can be set up with a value list for selecting Artists records by their ID field.
For an explanation of the notation that I am using, see the first post of: Common Forum Relationship and Field Notations Explained
Hi there. In this case it's not necessary to have a separate Artist ID because we're sorting on a project by project basis and not an artist by artist basis. We've got a separate filer set up if we need to drill into which artist was sent where. The big question is: if the portal is pulling information based on the Job ID field then shouldn't it be pulling all instances of that Job ID?
I'm sorry but that makes no sense to me. You may be sorting on a project by project basis, but to see info on multiple artists submitted for the same job requires the use of an artists ID field in a many to many relationship.
You'll need to explain the intended design of this portal, what relationship you have defined and whether or not you are using a portal filter. That will narrow down the possible issues with regards to whether the set up of the portal is not correct or if you do not have the correct data in the records you expect to see in the portal.