If you want to filter by user, you have to use some data element tied to a user's WordPress record. Since you don't want to use current_user, you have to provide a way for a user to enter a user to filter your view. The frm_after_create_entry action has nothing to do with views.

Thanks Victor. 
Yes, that is the pickle I'm in. The general public that will be viewing the created posts will not be activiely filtering the view by interacting with a form or anything, so I am trying to see if there is a way to use a query in the url to pass a value dynamically to a filter hook in WP Code or something like that to make sure that the correct entries are displayed on the front end. 
I have been looking into other ways I might possibly achieve my end goal without relying on filters at all. There is a script that uses the 'frm_after_create_entry' hook to break the View and Post connection after a post is created via a form, which may take care of the unique content side of this, but then I lose the ability to update the post via the original post creation form, which also needs to be a feature. 
Another way may revolve around using the 'frm_after_create_entry' hook to delete all entries but keep the created post. This would preserve the form's updating capabilities, but would not save the user's previous entries, which introduces another set of problems.
In any case, thanks again for your reply. I'll see if I can find a solution.  

So, turns out I didn't need to do anything. I guess the SSOT structure keeps the posts properly linked to the right content by default. Thanks for your help.