Yeah, I agree. This will require the same amount of filters as below. I missed the execution order in my previous post. The filter(s) should fire at an execution order less than the one that is causing the error message and the GOTO action should be one greater than the object causing the error.
The advantage is that you are just creating custom objects without messing OOB work-flow and since the tag is unique, nothing is affected. Thanks Mahesh On Thu, Jun 3, 2010 at 5:22 PM, Thad K Esser <tkes...@regence.com> wrote: > ** > That's a good general strategy, however for this type of integration, the > workflow on CTM:People should fire (sets up user records, default values, > etc). The filters listed are ones that can be safely bypassed by an > automated process that is designed to create and/or update the people > records. Also note that the execution order for these filters are all over > the place, so you'd have to put the bypass in in multiple places. > > *Thad Esser* > Remedy Developer > > > From: Mahesh <mchand...@gmail.com> To: arslist@ARSLIST.ORG Date: 06/03/2010 > 02:54 PM Subject: Re: User AR_ESCALATOR Sent by: "Action Request System > discussion list(ARSList)" <arslist@ARSLIST.ORG> > ------------------------------ > > > > ** If you want to stay away from touching the OOB work-flow and minimize > the maintenance effort especially during patch/version upgrade, you can do > the following. > > 1. Pass a "z1D Action" tag value to the People record along with other > values. Example: "XXX:PPL:Update". I use company abbreviation in place of > XXX. > > 2. Using the above tag as "Run If" qualification, create a filter to bypass > the workflow that is causing the issue (GOTO action). > > Thanks > Mahesh > > On Thu, Jun 3, 2010 at 1:46 PM, Thad K Esser > <*tkes...@regence.com*<tkes...@regence.com>> > wrote: > ** > Kevin, > > In order to get our integration to work, I added "AND ($USER$ != > "AR_ESCALATOR" )" to the run if of the following filters (ITSM 7.0.3 p9, > ARS 7.1) > CTM:PPL:VerifyManageInfo_142_Msg > CTM:PPL:GetStatusRuleSet_030 > CTM:PPL:VerifyManageInfo_141_Check > CTM:PPL:ChkUnrestrictedAccess-Fail2_596 > CTM:PPL:ChkUnrestrictedAccess-Fail_596 > > Also, the CTM:PPL:UpdateLoginID_795 filter uses TR values on the Remedy > Login ID field, so if you are pushing that field to CTM:People and it hasn't > changed, a whole bunch (no, really, a lot) of workflow will fire needlessly. > * > Thad Esser* > Remedy Developer > > From: "Maher, Jeff" <*jma...@fas.harvard.edu* <jma...@fas.harvard.edu>> > To: *arsl...@arslist.org* <arslist@ARSLIST.ORG> Date: 06/03/2010 11:32 AM > Subject: Re: User AR_ESCALATOR Sent by: "Action Request System discussion > list(ARSList)" <*arsl...@arslist.org* <arslist@ARSLIST.ORG>> > > ------------------------------ > > > > ** > > Hi Kevin, I had a similar issue, but it was actually caused somewhere in > the process of upgrading to ITSM 7 patch 9 from patch 4. There was some new > filter workflow added (or fixed so it actually did something) that now > checks roles when creating new users, login id’s, etc. A little bit of > logging and you can find the bugger that is missing ‘AND $USER$ != > “AR_ESCALATOR”’ in the qualification so your stuff will work again. However > like Joe said, probably is a better choice to do something using the AIE. I > didn’t really have that option in my scenario. > * > From:* Action Request System discussion list(ARSList) [* > mailto:arsl...@arslist.org* <arslist@ARSLIST.ORG>] *On Behalf Of *Kevin > Begosh* > Sent:* Thursday, June 03, 2010 1:42 PM* > To:* *arsl...@arslist.org* <arslist@ARSLIST.ORG>* > Subject:* Re: User AR_ESCALATOR > > ** this was working with 7.1, we just upgraded to 7.5 and getting these > messages now. Good suggestion with the AIE though. > On Thu, Jun 3, 2010 at 1:34 PM, Joe D'Souza > <*jdso...@shyle.net*<jdso...@shyle.net>> > wrote: > ** > ITSM 7 has changed a few things as to what roles are required to create and > maintain contact information.. The roles that you see have to be added to > the user that creates or updates this information in the CTM:People form.. > > Instead of using escalations to do what you are doing, I would suggest > creating a regular AR User account that has all these roles, and other > permissions needed, and use AIE to do the same thing you are doing.. I have > done it that way and it works well.. You can schedule AIE to run the job > just like you are using your Escalation.. Make sure you configure AIE to use > the user that you have created.. > > Joe > -----Original Message-----* > From:* Action Request System discussion list(ARSList) [mailto:* > arsl...@arslist.org* <arslist@ARSLIST.ORG>]*On Behalf Of *Kevin Begosh* > Sent:* Thursday, June 03, 2010 1:27 PM* > To:* *arsl...@arslist.org* <arslist@ARSLIST.ORG> * > Subject:* User AR_ESCALATOR > ** > I have a process and staging forms that pull employee data from a view form > on remedy, send it to a staging form and then creates a people record if > that ID does not exist on the people form. Well it worked before and then > we upgraded from 7.0 to 7.5 AR Server and now it is not working. We are > getting the following error message > > You must have one of the following permissions to create a person with a > login ID: 'Contact Organization Admin', 'Contact Support Admin'. (ARERR > 45530) > > and none of the profiles are being create. Has something change with > AR_ESCALATOR between 7.0 and 7.5? Am I missing something? > > ARS 7.5 Patch 4 > ITSM 7.03 Patch 9 > CMDB 7.6 Patch 1 > > -- > Kevin Begosh > _attend WWRUG10 *www.wwrug.com* <http://www.wwrug.com/> ARSlist: "Where > the Answers Are"_ > > > > -- > Kevin Begosh > _attend WWRUG10 *www.wwrug.com* <http://www.wwrug.com/> ARSlist: "Where > the Answers Are"_ > > _attend WWRUG10 *www.wwrug.com* <http://www.wwrug.com/> ARSlist: "Where > the Answers Are"_ > > *IMPORTANT NOTICE: This communication, including any attachment, contains > information that may be confidential or privileged, and is intended solely > for the entity or individual to whom it is addressed. If you are not the > intended recipient, you should delete this message and are hereby notified > that any disclosure, copying, or distribution of this message is strictly > prohibited. Nothing in this email, including any attachment, is intended to > be a legally binding signature. * > > _attend WWRUG10 *www.wwrug.com* <http://www.wwrug.com/> ARSlist: "Where > the Answers Are"_ > > _attend WWRUG10 www.wwrug.com ARSlist: "Where the Answers Are"_ > > *IMPORTANT NOTICE: This communication, including any attachment, contains > information that may be confidential or privileged, and is intended solely > for the entity or individual to whom it is addressed. If you are not the > intended recipient, you should delete this message and are hereby notified > that any disclosure, copying, or distribution of this message is strictly > prohibited. Nothing in this email, including any attachment, is intended to > be a legally binding signature. * > _attend WWRUG10 www.wwrug.com ARSlist: "Where the Answers Are"_ _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug10 www.wwrug.com ARSlist: "Where the Answers Are"
