So, it's changing the degree of normalization of the data model. That doesn't sound quite like what Remedy is doing in v9, but it seems to be moving in that direction. For better or worse, that structure has defined Remedy from its competitors through the years.
Rick On May 15, 2015 9:17 AM, "LJ LongWing" <[email protected]> wrote: > ** > It's been a few years since I took the Force.com training....but I seem to > remember that you could say something similar to 'I want this field on this > form to be the value on that form (here is the definition of how to get the > other value 'association')....and then from that point forward, the two > values were the same...not to say that it stored it in two places and > synchronized it...it stored it in one place, and made the other place a > reference to the first place. > > This would essentially be a new 'type' of field, a reference field, that > would never contain its own data, but instead, be a reference to the other > data....kinda like a symbolic link works with file systems....that would be > kinda cool. > > On Fri, May 15, 2015 at 10:11 AM, Thad Esser <[email protected]> wrote: > >> ** >> Doug, >> >> From what I'm understanding, this feature is currently geared toward >> whether or not the associated records exist. Any chance it could develop >> into also being data-focused? For example, let's say you have a People >> form and someone's Full Name changes. You could then define associations >> to other forms in such a way, that the Full Name field on the associated >> forms updates automatically. Sure, this is done with filters now, but you >> have to keep track of everywhere the data needs to flow. I suppose >> associations doesn't change that, but then it would be part of the data >> model at least. >> >> Or stepping back a level - maybe not just data-focused, but associating >> fields into a group on a given record. For example, let's say you have a >> Service Request form, with a group of fields that represent the "Requested >> For" person.. First Name, Middle Initial, Last Name, Login ID, Person ID, >> etc. Changing the Login ID or Person ID, would then change all the >> others. Middle Initial seems to be a favorite of BMC's to forget. Having >> an association defined with automatic updates might help. It has gotten >> more consistent with 8.1 and the service calls, so maybe I'm carrying some >> baggage on this one. :-) >> >> Anyway, looking forward to the future, >> Thad >> >> On Thu, May 14, 2015 at 11:57 AM, Mueller, Doug <[email protected]> >> wrote: >> >>> ** >>> >>> Thad, >>> >>> >>> >>> Yes, the Association feature is a major new feature. And, the 9.0 >>> release has introduced the basics and the possibilities and leverage of the >>> feature are just getting started. >>> >>> >>> >>> The 9.0 release uses the Association feature in two major ways: >>> >>> >>> >>> 1) To delete child records when the required parent record is >>> deleted. So, if you have a master record and then have other forms with >>> additional details, the association will automatically delete the children >>> when the parent is deleted. Associations have a configuration for whether >>> they enforce this flow or not. >>> >>> 2) For archiving. So, archiving the parent, takes all the >>> children with it automatically. >>> >>> >>> >>> Now, the base feature is about defining the relationships and >>> interconnections of forms – directly and through association tables. You >>> can follow the associations for any number of reasons. >>> >>> >>> >>> Think about some other things: >>> >>> >>> >>> Producing an diagram of the relationship of forms to form an application >>> is now a simple matter of following relationships AND you know whether the >>> association is a dependent relationship or not. >>> >>> >>> >>> What if DSO could be configured to “follow associations” so that >>> transferring the parent record would transfer all children records too? >>> >>> >>> >>> What if we could configure the system to have row level security flow to >>> children from the parent so any change to a row level security field on the >>> parent flows that change to all children records as well? >>> >>> >>> >>> What if you could define table fields to just “follow the association” >>> rather than having to define the target form and qualifications on it? >>> >>> >>> >>> What if you could export data by just specifying the parent record and >>> all children record are exported along with it (or imported..). >>> >>> >>> >>> What if… >>> >>> >>> >>> There is a lot more that this feature can do and will allow. >>> >>> Working with applications that involve collections of forms with >>> inter-dependent or just inter-related data will be much easier and will be >>> able to be done in a more global, consistent, and systematic way rather >>> than custom logic for each set of interaction. >>> >>> >>> >>> >>> As an aside, there is also much more that is possible with archiving now >>> that this is in place and you should see some very cool new features >>> related to archive still to come in releases post 9.0. >>> >>> >>> >>> >>> >>> I am glad that you are seeing some of the possibilities that this >>> feature opens up within the system – some available already (archiving and >>> delete) and others to come. There are additional features – both with 9.0 >>> and some coming beyond that will also provide basic capability that can >>> then be leveraged in many different ways. (One of my favorites by the way >>> is the dev-to-production or packaging or deployment manager – whatever name >>> they settled on – feature. It has a lot of value in 9.0 and there is much >>> more coming that will help transform how promotion of change is done within >>> the environment.) >>> >>> >>> >>> As always, we would love to hear what you are doing with the features, >>> how you are leveraging them beyond the defined uses. And, what is missing >>> from them that would make the functionality even more powerful. >>> >>> >>> >>> Doug Mueller >>> >>> >>> >>> *From:* Action Request System discussion list(ARSList) [mailto: >>> [email protected]] *On Behalf Of *Thad Esser >>> *Sent:* Thursday, May 14, 2015 9:38 AM >>> *To:* [email protected] >>> *Subject:* ARS v9.0 - New Server Object - Associations >>> >>> >>> >>> ** >>> >>> Has anyone else taken a look at the new "Association" server object for >>> version 9.0? I've only read the docs (haven't played with it yet), but >>> this seem like a huge new feature, with possibilities way beyond just >>> archiving (which is what the docs say its being used for). >>> >>> >>> https://docs.bmc.com/docs/display/public/ars9000/Associations+overview >>> https://www.youtube.com/watch?v=E4v0X2SimKY >>> >>> >>> >>> Just curious what others thought, or if I'm nerd-ing out too much. >>> >>> >>> >>> Thad >>> >>> _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_ >> > > _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"
