With the introduction of multiple sandboxes in the Summer 07 release, is there any way that an org can spawn more than one *non* quick copy sandbox? Logging into my production org now, when I go to data management > sandbox and try to create a second sandbox (the existing sandbox is a complete copy), the option to check or uncheck "Quick" is disabled and is defaulted to checked.
Is this a technical barrier or more of a licensing and cost barrier? For reasons that aren't really pertinent to the conversation, our org really would ideally have 2 full copies--any subsequent sandboxes spawned would be fine as quick copies.
Tried to find an analagous thread by searching but couldn't find anything germaine to my question--
When a lead is converted within the Salesforce GUI, does that lead still show up inside of general SOQL queries? The behavior on the website when you do assorted searches and what not is to not display that lead. If you try to go to the lead by its ID in the URL directly, you get a friendly error message saying the lead is already converted.
If I did a SOQL that was effecitvely "SELECT Id FROM Lead WHERE Email = 'foo@foobar.com'", would that guy still show up or does one specifically have to denote IsConverted as part of the query?
I could have sworn that lead queries were mimicking the behavior seen on the site, but we've recently started to see this not be the case. I'm somewhat perplexed since we'd been working against the assumption that was true, so I theoretically should have seen some of the error behavior I'm seeing now much sooner, since that assumption is baked into some of our S-Controls and other integration pieces at a fairly low level.
Is there any other special behavior of a converted lead that one ought to be aware of? (i.e. the fields are read only post convert?)
I'm in the process of deprecating a good number of fields on our lead and account objects (as part of a process we're undergoing here to restructure how we're modeling our data in Salesforce) and am hitting a wall with deleting some of our custom fields.
In several cases, in deleting a field, I was notified that a field was being referenced, and a link would be supplied to where the offending field was in use (typically in a custom link or button). There's a good dozen however where I'm getting the same error, but this time instead of an actual useful bit of information, I get bupkis.
Instead, I get an error stating that the requested change can't be completed; reason: "This custom field is referenced elsewhere in Salesforce." Section: "This custom field is referenced elsewhere in Salesforce." So I've been clicking around anywhere that seems to make sense--I've scoured S-Controls, custom links, workflow rules, lead field mappings--and for the life of me I can't identify where these references exist. To say this process is frustrating is a colossal understatement.
Anyone have pointers on another approach I might be able to approach to try to figure out where else I need to sever these references?
I'm trying to build out web to lead like functionality without using the actual web to lead process but am running into some difficulty. (We'd considered web to lead, after some inspection, we weren't happy with certain privacy issues and the ability to filter web to lead submissions from a specific URL or domain).
More specifically, I can't seem to get emails on my lead assignment rules to fire. High level, we have 3 core requirements:
1) create lead (check) 2) assign lead to proper queue based on lead source (check) 3) shoot out email to the queue's email address (no go)
After some research, we'd learned that we had to specify our WSDL binding's assignment rule header and email headers. We're apparently using the assignment rule header correctly as we're properly seeing our assignment rule fire and attach the newly created lead to the proper queue. We're apparently doing something wrong w/ our email header OR we've got our lead assignment rule set up wrong (simply specified an email template, queue is set w/ an email address but not marked to email members of the queue).
Snippet of code on our proxy to Salesforce below:
//assignment rule header _binding.AssignmentRuleHeaderValue = new AssignmentRuleHeader(); _binding.AssignmentRuleHeaderValue.useDefaultRule = true;
//email header _binding.EmailHeaderValue = new EmailHeader(); _binding.EmailHeaderValue.triggerAutoResponseEmail = true;
The official API docs are a bit sparse on the EmailHeader object (comes in at basically a paragraph) and none of the searches on the dev forums about the header seem to quite match what I'm trying to do. For example I'm not sure I truly understand the delineation between an Auto Response Email, Other Email or User Email when it pertains to the Email Header.
Any one have any pointers that might be able to nudge me in the right direction?
I'm attempting to prototype some simple outbound messaging scenarios with my Sandbox instance. Looking at the API docs for Winter07, a note is made that
"To avoid an infinite loop of outbound messages that trigger changes that trigger more outbound messages, we recommend that you update objects with a user whose profile has the PermissionsDisableNotifications set to true"
Try as I have within AppEx Builder I can't find the particular option as an assignable value. Out of curiosity, I checked using SForceExplorer on the User object. Found similarly named permission flags for marking a user as offline or as an AvantGo user, but nothing that looked remotely related to OM. I also tried a cursory search on my live instance as well as on a dev instance with the same results.
I'm not gated by this and my end point to consume the outbound message isn't going to do anything of note, so the fear of an infinite loop of messaging is remote. However once we do prepare to roll live with this, this might be of greater concern, so knowing where to set this and adding it to our deploy checklist would be great... :P
Am I just blind and absolutely glossing over it somehow?
With the introduction of multiple sandboxes in the Summer 07 release, is there any way that an org can spawn more than one *non* quick copy sandbox? Logging into my production org now, when I go to data management > sandbox and try to create a second sandbox (the existing sandbox is a complete copy), the option to check or uncheck "Quick" is disabled and is defaulted to checked.
Is this a technical barrier or more of a licensing and cost barrier? For reasons that aren't really pertinent to the conversation, our org really would ideally have 2 full copies--any subsequent sandboxes spawned would be fine as quick copies.
I'm trying to build out web to lead like functionality without using the actual web to lead process but am running into some difficulty. (We'd considered web to lead, after some inspection, we weren't happy with certain privacy issues and the ability to filter web to lead submissions from a specific URL or domain).
More specifically, I can't seem to get emails on my lead assignment rules to fire. High level, we have 3 core requirements:
1) create lead (check) 2) assign lead to proper queue based on lead source (check) 3) shoot out email to the queue's email address (no go)
After some research, we'd learned that we had to specify our WSDL binding's assignment rule header and email headers. We're apparently using the assignment rule header correctly as we're properly seeing our assignment rule fire and attach the newly created lead to the proper queue. We're apparently doing something wrong w/ our email header OR we've got our lead assignment rule set up wrong (simply specified an email template, queue is set w/ an email address but not marked to email members of the queue).
Snippet of code on our proxy to Salesforce below:
//assignment rule header _binding.AssignmentRuleHeaderValue = new AssignmentRuleHeader(); _binding.AssignmentRuleHeaderValue.useDefaultRule = true;
//email header _binding.EmailHeaderValue = new EmailHeader(); _binding.EmailHeaderValue.triggerAutoResponseEmail = true;
The official API docs are a bit sparse on the EmailHeader object (comes in at basically a paragraph) and none of the searches on the dev forums about the header seem to quite match what I'm trying to do. For example I'm not sure I truly understand the delineation between an Auto Response Email, Other Email or User Email when it pertains to the Email Header.
Any one have any pointers that might be able to nudge me in the right direction?
I'm attempting to prototype some simple outbound messaging scenarios with my Sandbox instance. Looking at the API docs for Winter07, a note is made that
"To avoid an infinite loop of outbound messages that trigger changes that trigger more outbound messages, we recommend that you update objects with a user whose profile has the PermissionsDisableNotifications set to true"
Try as I have within AppEx Builder I can't find the particular option as an assignable value. Out of curiosity, I checked using SForceExplorer on the User object. Found similarly named permission flags for marking a user as offline or as an AvantGo user, but nothing that looked remotely related to OM. I also tried a cursory search on my live instance as well as on a dev instance with the same results.
I'm not gated by this and my end point to consume the outbound message isn't going to do anything of note, so the fear of an infinite loop of messaging is remote. However once we do prepare to roll live with this, this might be of greater concern, so knowing where to set this and adding it to our deploy checklist would be great... :P
Am I just blind and absolutely glossing over it somehow?
1) If Salesforce.com Web servers are in maintenance mode, are API servers still available? 2) If Salesforce.com Web servers down, API servers down too?
