Is it possible to have certain profile fields "Optional" when a request is being made but "Required" before the project is generated?  It would be useful for us to allow for submission of requests so they can be evaluated before every piece of data we collect is known. 

In essence can you have different Optional/Required settings for approvals and projects

Thanks Steve.  I want to make sure I'm clear on the process your suggesting. 

"When you edit, and a required field is exposed (that wasn't required on the request form) then you have to put in data before saving again." - I presume your implying that a previously "Optional" or not shown field was added to the request form and set as "Required" by the Administrator in between the initial request submittal and a subsequent edit.  Is that correct? 

Assuming yes I can't see how that would be a practical/scalable solution (I don't think you were suggesting it would be either.  You were just explaining how it could be done.).  Do you know if there is any intention of providing the level of flexability/customization I am referring to?

 Thanks,

Jim

Let me clarify a little more.  I have 2 custom fields in existence already and their location:

• Desired Completion Date and it is a Date field. 
  
• On the Request
• Budget Authorized Amount and it is a Currency field. 
  
• Not on the Request, but is required
  

 User submits their project request and plugs in the desired completion date and all other fields.  Once in Daptiv, the Exec (or designated person) reviews the request and selects the Edit option to revise the Desired Completion Date for whatever reason.  As soon as the Exec hits Save, they get a message that says "Budget Authorized Amount is a required field"  Because it was not on the form, it was blank - since the Edit action exposes that blank field which is required, you can't save until it is filled in.

We're not adding new fields or anything to either the system or the form.  It is possible to create a required field in the system and not include that field on your request form.  Is that a clearer?  Let me know.

Also - Picklists style fields (including Yes/No, members etc...) unfortunately are not smart enough to detect user interaction which means that the default setting satisfies the requirement.  This is a design shortfall in our product which our Product team is aware of.  

I see.  I'm still learning my way around the application and didn't make the distinction about something being required as part of the request vs. part of the project.  I've played around and seen the scenario you explained.  I may be able to use this to help us get where we want.

 Thanks.