Apex Code Development You need to sign in to do that
Don't have an account?
mannar automatically populates region field based on zip codes, US states and countries.
“We have developed code using standard Apex language Trigger feature that automatically populates a field with geography information based on zip codes, US states and countries. As we could not get the information from Apex guide on the usage of picklists for Zipcodes, states and countries, we had to hardcode the literals for zipcodes, states and countries in the trigger for checking. We made the code working but it has become unreadable. My precise questions:
1. How do we use picklists in Triggers?
2. Salesforce.com has not made Triggers available in Enterprise edition yet and we need to go live with the functionality in production; is there any other alternative you can suggest?
3. We were given a non-Apex language alternative to use but the byte size of the code is more than 1000 characters.
So far we have only received generic responses to similar queries. Can you pls provide specific responses?
What we are requesting is not a new feature from SF.com – rather we want to know how to use the existing feature effiectively.”
Salesforce.com does not support the standard zipcode, city or state fields as picklists. You can create a custom fields that are picklists for these fields but you must maintain the values manually. You can access the value for a picklist field on a particular object but you can not access the metadata for the picklist values available for a given field.
2. There are two alternatives today:
a) create an scontrol and maintain the logic in client-side code (javascript most likely) which limits your assignment to UI interactions (No API).
b) host the logic on external servers. You can invoke that two ways - receive an outbound message as a result of a workflow rule or poll salesforce for unassigned records.
Back to your Apex code design. I would not suggest maintaining this mapping information as literals in your code. You should consider creating a custom object that persists this information. If you decide to do that, you should make the ZipCode field an 'External ID' which will provide 2 benefits: 1) the field is indexed so your queries will be much more efficient and 2) if you need to maintain this table you can use the upsert verb against zipcode which makes data mgmt and integrations much easier to maintain.
A project I worked on needed to do something similar. Based upon the country value, we set a Region and Sub-Region field. This was happening on Leads, Account and Contacts.
We did this using Workflow Field Updates and it worked pretty well. We would have liked to use formulas, but we ran out of room because of how formulas handle picklist (requires you to use the ISPICKVAL function). We hit the max length of formulas pretty quickly.
First off, we had to use custom address fields so that we could use picklists for our country values. We filled the list of countries with the ISO standard values.
We then created Field Updated Rules to do the updates. For example, we had a workflow rule called Account.SubRegion=North America. Workflow Rule criteria are able to read picklist values without issue. Our criteria used OR statements and listed all the countries in North America. The rule then triggered 2 field update: 1) set Region = "Americas" 2) set Sub-Region = "North America".
The only downside to our solution is that these workflow rules fired AFTER Lead Assignment and Territory Rules, so we were unable to use the Region & Sub-Region values in our assignment rules, which would make things A LOT more managable. However, they do come in handy for reporting purposes.
I would NOT recommend this solution if you have to take your logic all the way to zip codes. You will pull your hair out trying to manage it. Unless our rules are very high level and you can do things like "starts with".
I would recommend you go with mtbclimbers recommendation #2. Store all your zipcode to region mappings in a nice, clean database table. Receive an outbound message when a record is updated (or poll the application every n minutes) and do your lookup against the table and update SFDC via the API. Only real downside to this is that there will be a slight delay and the Last Updated By field will be updated with a different user's name. If you wanted to get really fancy, you could use an Outbound Message passing in the session ID of the user, then leverage that for logging into the system so the Last Updated By information is actually the user that originally updated the record. You'll need to add error handling, though, to be able to login as a different user if the session has expired (e.g. your messages are help up in a queue for whatever reason and you have to process old messages).
Good luck!