Your comments

Good idea!  But it still requires the user to copy and paste in the current Project ID. I don't see the Project ID as and available field to copy or set to another EA. Or am I missing it?

yes, basically we want a subset of attachments that the user can select from a task to move forward to a review.  They would have multiple of the same attachment type in a project that are all limited by that project's visibility but only want one or two of them to flow to the next task (review task) to the reviewer isn't looking at all the different attachments.  This is an odd case where versioning isn't appropriate for the most current file.

sorry for the delay on this. I lost track of this one.

I would think that it would be more of an Existing Project Attachment option.  Obviously if it's an attachment at the activity level, it's automatically visible at the project level.  This is more of the case where we have users that need the same attachment to show up in specific multiple workflows. For example.  We have creative projects and approval projects. Users should be leveraging the integrated approval process within the creative process.  However, many times they do not which causes them to upload the same document a 2nd time into the approval project because they don't know how to associate the attachment to a different project. If instead of forcing a new upload, we could give them the option to select an attachment that is limited to another project that would limit the duplicate attachments, and seamlessly associate the  annotations to the attachment and make them visible across the appropriate projects. We can't move the attachments to the activity level because there are multiple projects happening at once.

There are other use cases we have where user error isn't the reason, that I can share if you need.

I have other uses for a separate domain right on task worksheet that I would love this. So many times our users go into that view and mess up their workflow.  Please add that domain right!

It's not so much for input into that specific task, but rather within a task in the process the users want the ability to change the data on the fields so we make them editable. 

We are working now to prepare for task inbox with a redesign of all of our DCTs to move the required fields up into a displayed section and the non required into a collapsed section, but it doesn't always make sense due to cascading values and data flow. Sometimes we will have to mix the required in with the non required due to cascading sections.

I get it, but I'm not sure google is using this in the way our groups are where we have 15-20 fields on a task.  I am wondering if it would be easier to see "Required" instead of optional.

Could you provide mock ups that show both ways so we could share with our users? I'm just concerned that it will actually be more difficult to find the required fields when 12 of the 15 fields on the screen say Optional.  A sea of optional!

What if the field is read only?  will you be displaying optional after each one?  I don't think I agree with adding this text to every non required field, especially if it's read only. I'll have to bring this back to our users for input.  I am curious as to what the rest of the user community thinks. 

Eric,

Do you have a date on this one for early adopter or when it will be behind a feature flag?

Yes, but multi-selects do not count against the 1024 as they are in a different table.

We've had this issue as well where sometimes we have to require uploads based on scenarios. Today we have to solve for this by routing the tasks differently which has lead to some duplicate tasks, back to back tasks for users, or just not making the uploads required which leads to higher reject rates in subsequent review steps when documents are missing.  So I actually think this would simplify our configuration and improve the user experience as it would allow is to manage the document uploads in one place vs having a clunky configuration.