not tried it, but it would look something like this:
Inside Salesforce.pm, locate the sub create() , modify this sub to add a header to the create call to set the AssignmentRuleHeader
my example is based on query, so to set a batch size i use my $batchsize = SOAP::Header->name('batchSize' => $in{'limit'}); my $qry_opts = SOAP::Header->name('QueryOptions' => \$batchsize);
then from the api help --- useDefaultRule boolean
Specifies whether to use the default rule for rule-based assignment (True) or not (False). The default rule is assigned by users in the Salesforce user interface. ------------------------------
so you would do something like this my $autoassign = SOAP::Header->name('useDefaultRule' => 'true' ); my $assign_hdr = SOAP::Header->name('AssignmentRuleHeader' => \$autoassign );
# then modify the client call to include this header
I believe that using the default assignment rule should be the default, as it was in the old servlet-based WebToLead method. Is anyone currently maintaining the Salesforce.pm, etc, that we PERL developers are using?
I don't think it's been updated recently, my version has diverged because it has custom objects listed inside the module, not the WSDL support that i would really like.
By the way, I did try to do this, and I STILL did not get the auto-assignment I expected. The Salesforce 'experts' here at work say that my rules are set up correctly, but for some reason, the leads are always assigned to the user with which I called 'login', rather than the default queue, or any of the queues mentioned in the leads. My xsi:type is a little different from the one in your example (sfons vs. sforce), but I am well outside of my SOAP comfort range at this point, so I have no idea if that is an issue.
You asked for it. :) I did *** out my password, and you can see a couple of my own debugs in there. I see the AssignmentRuleHeader in there, so I have no idea what is going on. The same thing happens both in my development account (william@x1.com) and the live account, where the old servlet.WebToLead stuff still works fine.
enough of this got chopped out to make it not usefull to debug i think you need to to replace < and > with [ and ] so we can see the soap envelope and body elements
Yeah, that was pretty rough. I replaced < and > with [ and ].
Related question: is it possible that, for some reason, my account simply does not have the capability to use the auto-assignment rules?
I tried to manually (through the browser interface) to create a Lead (and a Case), checking the 'assign using active assignment rules' box, and it gives me the error 'there is no active case assignment rule'.
SimonF wrote: The AssignmentRuleHeader needs to be in the urn:sobject.enterprise.soap.sforce.com namespace
Aha! Well, this is something. Ron or Simon (or anyone), any idea how to realize this in the current Salesforce.pm module?
I am still curious as to why my developer login (william@x1.com) does not allow me to manually create Leads (or Cases) with the auto assignment rules by checking the 'assign using active assignment rule' box.
trinity wrote: Change u to c in the following line in Salesforce.pm or your code.
https://www.salesforce.com/services/Soap/u/4.0
This does not seem to make any appreciable difference. I have modified the namespace in several places in order to try to conform to Simon's suggestion, again with no effect on the non-performing auto-assignment rules.
Since I cannot even create one manually, I am of the opinion that either (a) I have not correctly configured the rules, (b) my 'Developer' account does not allow their use. However, I would still appreciate any insight on changing the Salesforce.pm that I downloaded from sourceforge in order to call out the correct namespace.
# comment out partner namespace # my $uri = 'urn:partner.soap.sforce.com'; my $uri = 'urn:enterprise.soap.sforce.com'; my $sorun = 'urn:sobject.enterprise.soap.sforce.com';
near to top of the module to move everything into the enterprise name space, you must also search out and replace any hard-coded uses of 'urn:partner...' to use one of these two new variables
Also, i would really look into why your default rule does not fire when creating leads from within the app, then move on to testing to make sure it fires when using web2lead, then come back to the api problem.
sorry the perl module is giving so much trouble, if i get a chance to make a fresh start on changes i will.
I spoke to Nia at Salesforce Support, and it turns out that the default auto-assignment rule created when someone gets a new Developer account is defective. You have to COMPLETELY DELETE your auto-assignment rule, and create a new one from scratch. Deleting just the rule entries is not enough.
Once I did that, auto-assignment rules correctly kicked in when I manually (through the web interface) created a Lead. Also, they correctly kick in when I use Web-to-Lead (which I had to enable in Setup > Customize > Leads > Web-to-Lead before it would properly store them in the database).
Unfortunately, even after replacing all of the uri and sfons references in Salesforce.pm with variables, pointing to the ones you suggested, auto-assignment rules still do not kick in when I create a Lead that way. Would it be possible for you to post your version of Salesforce.pm that DOES work somewhere, so I can try it out to see if it makes a difference?
Nia Samady got back to me after I sent her my SOAP dump that we thought should have been working. It turns out that the AssignmentRuleHeader itself also had to be explicitly placed in the enterprise namespace.
So in create:
my $uri = "urn:enterprise.soap.sforce.com" ;
...
my $autoassign = SOAP::Header->name('useDefaultRule' => 'true' ); my $assign_hdr = SOAP::Header->name('AssignmentRuleHeader' => \$autoassign )->uri($uri) ;
Then pass the header through to the call as mentioned earlier ...
And remember, if you have a newly created Developer account, YOU MUST COMPLETELY DELETE ALL OF YOUR AUTO-ASSIGNMENT RULES, and then recreate them. The ones that are created by default do not work, for some reason. If you cannot manually create a Lead or Case using the web interface (using the 'Assign using active assignment rule' checkbox at the bottom of the new lead/new case page), you are already hosed.
I have the same issue as bild... I tried the same thing (changing the headers to include the default rule), which seems to show up OK in the SOAP headers, but does not apply the assignment rules properly.
Inside Salesforce.pm, locate the sub create() ,
modify this sub to add a header to the create call to set the AssignmentRuleHeader
my example is based on query, so to set a batch size i use
my $batchsize = SOAP::Header->name('batchSize' => $in{'limit'});
my $qry_opts = SOAP::Header->name('QueryOptions' => \$batchsize);
then from the api help ---
useDefaultRule boolean
Specifies whether to use the default rule for rule-based assignment (True) or not (False). The default rule is assigned by users in the Salesforce user interface.
------------------------------
so you would do something like this
my $autoassign = SOAP::Header->name('useDefaultRule' => 'true' );
my $assign_hdr = SOAP::Header->name('AssignmentRuleHeader' => \$autoassign );
# then modify the client call to include this header
my $r = $client->call($method =>
SOAP::Data->name('sObjects' => \SOAP::Data->value(@elems))
->attr( { 'xsi:type' => 'sforce:'.$type } ),
$self->get_session_header(), $assign_hdr );
all of this requirs you modify the Salesforce.pm module, best of luck.
By the way, I did try to do this, and I STILL did not get the auto-assignment I expected. The Salesforce 'experts' here at work say that my rules are set up correctly, but for some reason, the leads are always assigned to the user with which I called 'login', rather than the default queue, or any of the queues mentioned in the leads. My xsi:type is a little different from the one in your example (sfons vs. sforce), but I am well outside of my SOAP comfort range at this point, so I have no idea if that is an issue.
did you try to dump the return value from the create to see
if there was a fault or error?
the next step would be to capture the SOAP which is created by the SOAP::Lite
module and post it here so more eyes could look at it.
to get a trace of the soap i think you can just add the following trace
statement to your deserializer package decl inside Salesforce.PM
#
# BEGIN Deserializer
package Salesforce::Deserializer;
use SOAP::Lite +trace => 'debug' ;
i can try to reproduce this but it i'm not sure when.
Thanks for any insight you can give me,
b
i think you need to to replace < and > with [ and ] so we can see the soap
envelope and body elements
thanks
Related question: is it possible that, for some reason, my account simply does not have the capability to use the auto-assignment rules?
I tried to manually (through the browser interface) to create a Lead (and a Case), checking the 'assign using active assignment rules' box, and it gives me the error 'there is no active case assignment rule'.
Message Edited by bild on 10-25-2005 12:05 PM
Aha! Well, this is something. Ron or Simon (or anyone), any idea how to realize this in the current Salesforce.pm module?
I am still curious as to why my developer login (william@x1.com) does not allow me to manually create Leads (or Cases) with the auto assignment rules by checking the 'assign using active assignment rule' box.
https://www.salesforce.com/services/Soap/u/4.0
This does not seem to make any appreciable difference. I have modified the namespace in several places in order to try to conform to Simon's suggestion, again with no effect on the non-performing auto-assignment rules.
Since I cannot even create one manually, I am of the opinion that either (a) I have not correctly configured the rules, (b) my 'Developer' account does not allow their use. However, I would still appreciate any insight on changing the Salesforce.pm that I downloaded from sourceforge in order to call out the correct namespace.
# comment out partner namespace
# my $uri = 'urn:partner.soap.sforce.com';
my $uri = 'urn:enterprise.soap.sforce.com';
my $sorun = 'urn:sobject.enterprise.soap.sforce.com';
near to top of the module to move everything into the enterprise name space, you must also search out
and replace any hard-coded uses of 'urn:partner...' to use one of these two new variables
Also, i would really look into why your default rule does not fire when creating leads from within the app, then move on to testing to make sure it fires when using web2lead, then come back to the api problem.
sorry the perl module is giving so much trouble, if i get a chance to make a fresh start on changes i will.
I spoke to Nia at Salesforce Support, and it turns out that the default auto-assignment rule created when someone gets a new Developer account is defective. You have to COMPLETELY DELETE your auto-assignment rule, and create a new one from scratch. Deleting just the rule entries is not enough.
Once I did that, auto-assignment rules correctly kicked in when I manually (through the web interface) created a Lead. Also, they correctly kick in when I use Web-to-Lead (which I had to enable in Setup > Customize > Leads > Web-to-Lead before it would properly store them in the database).
Unfortunately, even after replacing all of the uri and sfons references in Salesforce.pm with variables, pointing to the ones you suggested, auto-assignment rules still do not kick in when I create a Lead that way. Would it be possible for you to post your version of Salesforce.pm that DOES work somewhere, so I can try it out to see if it makes a difference?
may take me a few days, been sorta busy writing some new scontrols...
So in create:
Then pass the header through to the call as mentioned earlier ...
And remember, if you have a newly created Developer account, YOU MUST COMPLETELY DELETE ALL OF YOUR AUTO-ASSIGNMENT RULES, and then recreate them. The ones that are created by default do not work, for some reason. If you cannot manually create a Lead or Case using the web interface (using the 'Assign using active assignment rule' checkbox at the bottom of the new lead/new case page), you are already hosed.
Ben
Thanks!