This is a good discussion happening here.

The message "Print Operator field requires a valid user" means that no user is selected in the Print Operator field. This user is going to be the owner, therefore the value is required. It does not matter if the field is on the form or not on the form. If the field is required, it is required. 

A lot of testing has happened here, so I'll start from the beginning. As David mentioned, the steps are different if you want a single "owner" for the new items or if you want a group/queue to own the new items. We've been talking about a single owner for most of this conversation, so I'll stick with that assumption. If you would like to setup a group of users (or a queue) as the owner, let us know.

When you need an owner for a state: (Some of these steps you have already done, but it's good to validate each one.)

1) Create a new role (Print Team), if it does not already exist, for these users.

2) Create a user field (Print Operator).

3) Assign the Role (Print Team) to the field (Print Operator). This is done in Composer on the field properties "Options" tab. After you deploy, only the users with this role will be considered "valid" options for the field. Therefore, only these users will be valid owners for the state.

4) On the state, select the user field (Print Operator) as the owner.

5) Put the user field (this is "print operator", not the "owner" field) on the submit/transition form. If you do not want this field on the form, you will need to setup a default user who will be the owner of ALL new items in this state.(We'll do that later.) Either method works, but you have to choose. For troubleshooting, I would put the field on the form until you get everything working. Once, it's working, you can remove the field.

6) Deploy the changes.

7) Give some users and/or groups the new role (Print Team). This is a key step. Remember, only the users with this role will be allowed to own these items.

8) If you decided NOT to put the user field (Print Operator) on the form, setup a default user for this field. This user will be the owner of every new item. To setup the default user. Go under App Admin > Projects > open the project > Default Fields > Print Operator > Attributes > At the bottom of the "defaults" section, click the option for "manage user/group defaults", and pick a default user. Note: Only users with this role will be in the list of available users to chose from.

9) Submit a new item. Look at the user field (Print Operator). If you use the drop down, are the correct users in the list? If not, the users do not have the role for this field. If you setup a default user, was the default user selected?

Thank you Vicki for the detailed information.  I had already done steps 1 - 7.  The key was setting a default value for that field as we don't want to have to choose during submit.  

I tested with the field on the form and with it off.  It works great.  I now have a better understanding of how it works.  I've created workflows before, but they have always been a copy of an existing one.  This is the first time I created on from scratch.  Now on to setting up the notifications...

Thanks again.

Thank you Vicki for the detailed information.  I had already done steps 1 - 7.  The key was setting a default value for that field as we don't want to have to choose during submit.  

I tested with the field on the form and with it off.  It works great.  I now have a better understanding of how it works.  I've created workflows before, but they have always been a copy of an existing one.  This is the first time I created on from scratch.  Now on to setting up the notifications...

Thanks again.

Things to consider:

There is the "Composer" side of design and there is the "Application Administrator" side which is once a Workflow (aka App aka Process App) has been deployed to an Environment.  SBM supports an very strong "fence" between the design side and the deployed-onto-the-server side.

The designers that are working in "Composer" may have no knowledge of specific Users or Groups, i.e. names of actual Users or of Groups.  This is actually a requirement for some clients that I have supported in the banking and govt sectors.

The SBM Administrators that support the Workflow / Process App once it's been "thrown over the fence", i.e. deployed to a server are the folks that know about Real People, aka Users.  The Admins are the folks that create User accounts and Groups and assign Roles to those, which is generally how those Users get permissions to "do stuff".

Suggestion: Do NOT try to use SBM Groups to mimic your Org Chart .... use Groups to distribute collections of Roles and Permissions to individual Users or Groups based on what they're supposed to do.  My experience is that the Org Chart gets jumbled and re-organized on a regular basis.  If all your Workflow permissions are tied to the company Org chart, then you'll probably have to restructure your Groups when that happens.  Maybe not a problem with 20 users and 5 groups.  Definitely a BIG problem with 5000 Users and 50 Groups.

Another suggestion: Don't use Roles to mimic the Org Chart.  Use Roles to allow the "micro-assignment" of capabilities.  For example, all of our Process Apps have an "Administrator" Role that essentially has all privileges to do anything with any item in the Workflow at any time.  We also have the "User" Role (and maybe a couple others like "Reviewer" or "Investigator" in the pic below) that has the bare minimum level of capability to perform that function.  We then define additional Roles that are used in Composer to allow access to Transitions or to control sections on forms via Form Actions or JavaScript.  Many of these "narrow" Roles don't have any privileges defined ... they're just used by the automation to allow very specific capability.  The System Admins can then grant these Roles to individual users or to Groups.  We occasionally have to create a new Group to allow a category of users to get access to a new feature.