Calculated Fields in Request Offering Forms

Idea created by elysey on Apr 19, 2016
    Active
    Score60

    Currently the request offering forms allow us to auto populate a field based on the selection from another control e.g. select this person and auto populate email, phone and department to other appropriate text fields.  This works great but due to the fact that the trigger can only be based from the change of a single control, it hinders us from making forms smarter to assist with simplifying and standardising the workflow behind it.

     

    Example scenario:

    If the request is for the logged in user, then the approver is the logged in user's manager.  However if it is for someone else, then the approver is someone else's manager.

    This means you'll be dealing with 2 potential trigger points:

    - The selection of whether this is for the logged in user or someone else [TRIGGER 1]

    - The selection of that someone else [TRIGGER 2]

     

    To auto populate the field that would then be used to control who the approver is, we would need to have this triggering on possibilities of either the user changing in the form, TRIGGER 1 and/or 2.  Unfortunately the triggered by property can only accommodate for 1 control, and due to this, the workflow design will require an if block (to check if myself/someone else) and 2 approval blocks (1 approval block pointing to manager for myself and another to manager for someone else) instead of just 1 approval block pointing to a calculated field with the appropriate Manager Rec IDs.

     

    This is where something similar to a calculated field would be really handy, allowing you to just enter in the logic that will always be calculated on change of any control referenced within the script.  Note that the scenario above is just an example, but the applications to a calculated field could be limitless.