You can create a report with a leading part based upon the volunteer. Put their name in the leading part, delete the body of the report, sort by volunteer and preview. But it smacks of an underlying issue and I know you will need to know the unique Volunteers many times over and not just in a list view. Best to address the structure now...
Ideally, you should have:
Volunteers table (which holds one each person who volunteers) with -
VolunteerID (auto-enter FM serial number)
F_Name (drop spaces in field names - it will cause you problems)
L_Name ... etc
Actions table (which holds one each of what you currently have)
ActionID ( auto-enter FM serial number )
VolunteerID ( holds the ID number of the volunteer this record belongs to)
ActionDate ... etc
Relate the two using = on VolunteerID. This creates a one-to-many (1:n) relationship where one volunteer has many actions. But I think you might still be missing something here. Can one activity ever have more than one Volunteer assigned?
Please explain these actions themselves to help us understand your business need. You may need an Activity table which would hold one each of the types of activities available, such as:
ActivityID (auto-enter FM serial number)
ActivityType (whether Adult activity or Child activity)
Location ? or anything else unique to a specific activity
This then might be the result of this type of structure
Volunteers -< Actions >- Activities
Thank you so much that answered my question and then some! I had a feeling there was an issue with the way I was setting it up. I will go back to the drawing board with a lot more confidence.