Thanks for replies, I got it what I was looking for :)
On Fri, Jun 13, 2014 at 8:47 PM, Gadgil, Abhijeet <abhijeet_gad...@bmc.com> wrote: > ** > > > > 1. If the purpose of the field is simply to be used as a buffer and > store temporary values, we should add/reuse a display only field. > > In such cases, reuse is a better option, provided the field is not used > for any other operation in the same transaction. In case if there is no > free field, you can add a new one , since it adds no extra column to the > database. But just make sure you create those fields in custom mode, so > that there is no impact during upgrade. > > > > 2. If the field need to contain a record, then we should always > create a new ‘custom’ field rather than using an old one. BMC can any time > remove that field from the forms or change its value. > > > > > > *From:* Action Request System discussion list(ARSList) [mailto: > arslist@ARSLIST.ORG] *On Behalf Of *Ars Lister > *Sent:* 13 June 2014 21:48 > *To:* arslist@ARSLIST.ORG > *Subject:* Re: Upgrade suggestion > > > > ** > > Hi Ankita, > > > > If you can avoid using an OOTB field, that is best practice. Sometimes it > doesn't make sense to build a new field when an OOTB field can handle the > job. The biggest thing is to not modify existing workflow if you are in a > pre-7.6.04 environment. If new workflow will conflict or is just a tweak > to the qualifications, make a copy of it with some letters in the front > indicating ownership and/or customization (eg. BMS-<name of workflow > object> for Bristol Meyers Squibb if you worked there) and then disable the > original workflow object (active link, filter, escalation, etc.). This > way, any upgrades will pick up the original disabled object and if it needs > to modify it, it will. You should always do a snapshot of your DB and a > separate def of all non-OOTB forms, modified OOTB forms that have new > fields or fields that have changed parameters (which I do not suggest as > they may affect workflow to another form you are not aware of that carries > the field or a join form you are not aware of), and of all non-OOTB > workflow so you can import it into the new system post-upgrade. > > > > If you are working with a 7.6.04 version or later, then modify the object > in the Best Practice view as an overlay and you will be fine with an > upgrade. Upgrades won't mess with overlays. > > > > Hope that helps and good luck! > > > > > > > > On Friday, June 13, 2014 3:53 AM, Ankita Pankaj <ankita.panka...@gmail.com> > wrote: > > > > ** > > Hi All, > > What is the best practice while doing development adding new fields in the > form or analyze existing fields to utilize. > > Reason for asking this question: I am little confuse if I have utilized > existing fields for my use and as the creator of the field is BMC, they can > utilize it in future release. > In further releases, If BMC has added new workflows around that field and > I have also written some workflows , so during upgrade how it will impact > my functionality around that field? > > Thanks in advance > > -Ankita > > _ARSlist: "Where the Answers Are" and have been for 20 years_ > > > > _ARSlist: "Where the Answers Are" and have been for 20 years_ > _ARSlist: "Where the Answers Are" and have been for 20 years_ _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org "Where the Answers Are, and have been for 20 years"
