3 Replies Latest reply: Jul 12, 2013 3:07 PM by SeanKirkwood RSS

    Changes to objects in Unifier

    SeanKirkwood


      This was a question that came in from a Unifier user.  Since it is pretty common, I thought I would post it along with my response.

       

      We are wanting to approach our clients with Unifier however we have a number of them who change their business processes every six months or so. This could include changing the data that is captured within these business processes as well as the workflows. In addition their organizational business hierarchy may evolve.

       

      What analysis/design guidelines would you give with regards to shell hierarchy, shell and business processes?

        • 1. Re: Changes to objects in Unifier
          SeanKirkwood

            Changes to data (forms)

            This takes 2 formats usually:

           

          1. adding data to forms which means new fields
          2. removing data from forms, which means removing fields

           

          Adding data is pretty easy.  You simply

          1. create the new fields (data definitions and data elements as needed)
          2. mark the object (BP, shell, attribute form) as Draft in uDesigner
          3. add the DEs to forms as needed
          4. save the object and mark it Complete
          5. Reimport into uStage and test, then import to Production when satisfied
          6. If you added pulldowns or multi-select fields, you need to add values to the data definitions

           

          So, in this scenario, you now have existing records without this new data.  If the BP had a workflow, you may have records that reached End, or are still in routing.  You have to decide what you want to do with these existing records.  If they do not need the new data, no worries.  But, if they do need the new data, how do you get it there?  If the record is in routing and will go to a form that has the fields on it, great.  If there are many records at the end step, you could either add an editable form to the end step, allow users to change the data, then add a view form to the end step so no future records can have
          the data edited at that step.  Or you can allow bulk edit of the records so the new data can be added manually or via web services call. Keep in mind that the decisions you make here may affect what you do in uDesigner.

           

          Removing data is more simple.  If the object has gone to production, you cannot remove the fields from the form as that would rip holes in the database (bad!).  So, you simply add them to a hidden block on the form, which means that users cannot put that data in any more.  Follow steps 2-5 above, except you hide the fields on step 3.

           

          Changes to workflows

           

          This takes 2 formats usually:

          1. adding to a workflow
          2. removing steps, lines/elbows from a workflow

           

          In either case, if the BP has gone to production, you cannot make changes to a workflow.  If it has only gone to uStage, you can change the workflow.  Assuming the BP has gone to production:

          1.   mark the object (BP) as Draft in uDesigner
          2. copy the existing workflow to make a new workflow. Make changes to the new workflow as needed.
          3. save the object and mark it Complete
          4. Reimport into uStage and test, then import to Production when satisfied
            1. You will need to go to configuration for the BP and inactivate the old workflow (assuming you don’t want to use it any more)
            2. Activate the new workflow
            3. Do BP setup for the new workflow in existing projects or in templates and update projects

           

          Changes to shells

          This takes 2 formats usually:

          1. Adding a new shell to the hierarchy
          2. Removing shells from the hierarchy

           

          if you need to add a shell, you create it in uDesigner and import it to Unifier.  You configure it to establish its place in the hierarchy.  You can then go to existing shells and change their location to reflect where they now live in the hierarchy.

           

          If you need to remove a shell, you need to go to configuration and change the hierarchy to allow child shells of the about-to-be-removed shell to go somewhere else, then go to those shells
          and change their location to their new parent, then inactivate the removed shell in configuration.

          • 2. Re: Changes to objects in Unifier
            Marc DiNick

            Any suggestions for changing an incorrect data definition after it's been deployed to Production.  For example, a DE called Hours is initially designed with a DD of Integer.  After the BP was deployed and records created in Production using this DE, it was determined it should have been a DD of Decimal to accommodate half hours.  The Integer-based DE can't just hidden and replaced with a Decimal-based DE because of the historical records already created. 

             

            Are there any options to rectify this, particularly if the DE in question is on a Detail form?

             

            Thanks.

            • 3. Re: Changes to objects in Unifier
              SeanKirkwood

              Marc,

              You cannot change the DD associated to a DE once it is deployed to production.  So, you will have to create a new DE based on decimal DD and add that to the detail form.  You will need to hide the old DE.  Now the problem becomes how to get data from two different fields (old DE and new DE).  You might be able to create a 3rd DE (decimal DD) to add the old and new fields together and report on that.  Old records will not have any data in the new DE, new records will not have any data in the old DE, but hopfully all of them will have it in the total DE. If not, you can build the calculation into your reports or dashboards.

               

              Sean