locked
CRM 2011 Online workflows with multiple forms RRS feed

  • Question

  • I have multiple custom Entities for service repair records.  For the particular set of Entities I'm working on there is a Entity to hold the product (customer owned equipment) and an Entity for service repair records.  With custom workflows in a service form, once the necessary steps are completed and a trigger on the form changes to "Work Performed" I'm able to create a new "Future Scheduled" service form with future dates that sets reminders, sends emails, etc.  The existing completed form gets deactivated and all the pertinent info is copied to a new form for the next service schedule.  The problem is that this particular product has three custom forms because of the different types of services that have to be performed.  I'm trying to figure out how within a workflow to tell the Create Record option which form to use after the Entity is chosen.  Microsoft did a great job allowing multiple forms to be used within a given entity but not much documentation around on how to use workflows to create a new form when multiple forms exist for the Entity chosen.

    I have this sucessfully working on at least a dozen other sets of Entities but this is the only one where multiple forms are involved... I supposed I could create a seperate Entity for the two different types of services and relate them all back to the master Entity where the customer product record is kept.  Just a shame to recreate all that hard work again :).

    Monday, March 18, 2013 9:50 PM

Answers

  • If you are creating or updating an entity with a workflow, it should display the primary form, then underneath those fields, any fields not present on that form should be listed out and allow values to be set. With multiple form, different users have different access and this also allows you to populate fields that aren't on any form but might be used in other back-end processing.

    Jason Lattimer
    My Blog -  Follow me on Twitter -  LinkedIn

    Monday, March 18, 2013 10:41 PM
    Moderator

All replies

  • If you are creating or updating an entity with a workflow, it should display the primary form, then underneath those fields, any fields not present on that form should be listed out and allow values to be set. With multiple form, different users have different access and this also allows you to populate fields that aren't on any form but might be used in other back-end processing.

    Jason Lattimer
    My Blog -  Follow me on Twitter -  LinkedIn

    Monday, March 18, 2013 10:41 PM
    Moderator
  • I was thinking forms instead of fields... Obviously by pushing the necessary info to the correct fields (including additional fields at the bottom) then if the primary form isn't the correct one, just choose the correct one and you're all set.   I should have realized that.  Thank you very much!

    Larry

    Monday, March 18, 2013 11:44 PM
  • If you are creating or updating an entity with a workflow, it should display the primary form...

    What exactly is "the primary form"? It's not a term I have encountered before. It doesn't appear to have anything to do with "Form Order" or whether a form is enabled for fallback, or even the native "default" system form. In my case, my "primary form" on the Opportunity entity is a custom form (which some read-only attributes which is frustrating when designing workflows with create/update steps on this opportunity).

    Can this "primary form" be amended?


    Monday, May 20, 2013 10:26 AM
  • The Main form in this case is the same as the primary form for this thread. Are you using the new Dec 2012 update? If so, you have the new Main forms. Our company chose not to use the new form style because of the complexity of our Opportunity form... We just disabled the new forms and stuck with our original forms.
    Monday, May 20, 2013 11:28 AM
  • Edit: sorry I typed this assuming that Jason had replied, not you Larry! :) It's still useful clarification though.

    I'm still not sure that I understand... Forgive me for being pedantic, but is "primary form" just a phrase you have used ad hoc in this scenario? :)

    In my scenario, we have also opted to "ignore" the Updated (UR12) forms. Neither do we use the default opportunity form. Instead, we have created three different custom forms (lets call them "SME", "Corporate" and "SysAdmin"). SME and Corporate are only available for certain roles, but not explicitly System Administrators. SME is enabled for fallback. SysAdmin is for System Admins only. All other forms have had associated roles removed. Form order in CRM is set thusly:

    1. SME (available for fallback)
    2. Corporate
    3. SysAdmin

    When I log on as System Administrator and edit a workflow with an "Update Opportunity" step, I am presented with the Corporate form. This seems an almost random selection as it has no properties that I would deem to make it first choice. I would want SysAdmin as default, but I would understand (given sort order and fallback properties) SME to be used as default.


    Monday, May 20, 2013 11:39 AM
  • Yes it is, the form TYPE is Main.  When you go to customize forms for the entity you see the type I'm refering to.  The Main form is normally called the the same name as the entity... in this case, Opportunities.  We dissabled the new form and stuck with the old form.  Think of it in a different way... you have a bunch of fields available to enter data into.  The same field used on multiple forms will display the same data for any given record.  It's just a different VIEW of the same data, it's up to you the system admin to set which fields are visible on the various forms and to whom you give the privelege to see them.  So if one user would only be responsible for entering data into a small block of fields on the form he or she sees, form1 or whatever you want to name it is used... a second person could have all the first users fields plus a second block of fields for their responsibility and so on.  Just be careful of making fields required that aren't visible on all the form versions.  If you are trying to get a specific form to show, be sure to click the dropdown arrow on the left in the side navigation bar, from there you have access to the various forms you've created.

    There are so many different ways to use forms it's crazy customizable. 

    Monday, May 20, 2013 1:11 PM
  • Thanks Larry - I understand the concept of the forms in general (Main versus Mobile; not needing to use a specific form in the workflow designer etc).

    My particular problem is that the form that CRM presents to me as a System Administrator in the Workflow Designer seems to be chosen arbitrarily (but consistently). This is not normally a problem (since unused fields appear in an extra section at the end of the form, in the workflow designer), except that the form that CRM presents to me has some disabled fields on it (by design, they are readonly for end users). This is a problem for me when editing workflows, since the workflow designer won't allow me to set values in these fields. The only workaround I have at present is to edit the form to make the fields all editable, publish the form, edit my workflow, re-edit my form to make the fields readonly and then republish the form. If I had control over which form the workflow designer presented to me, then I wouldn't have a problem. 

    I was interested in Jason's response in particular since he referred to a term that was unfamiliar to me and suggested I may have missed something ("..primary form..."). :)

    The puzzling thing, as above, is that I cannot think of any logical criteria that justifies CRM's choice of form.


    Monday, May 20, 2013 1:21 PM
  • I understand your point.  I had to do the same thing with mine... I have about 70 workflows so far and because of the multi-form approach to certain entities I had to change the field from read-only to normal, change the workflow, then rechange the field back to read-only with the apprioriate publishing in-between.  My only thought is that Processes (workflows) are not dependant on any form, they are for fields.  Any workflow you build will affect fields and actions on fields (for the most part) and those changes and actions apply to all forms within a given entity.
    Monday, May 20, 2013 1:30 PM