With Web-to-Lead and Web-to-Case forms, Salesforce provides an easy way to connect your constituents to to your Salesforce database. All it takes is a few clicks: select the Lead or Case fields you want to include, and like magic Salesforce...
How One DevAdmin #LeveledUp at Dreamforce
More than one person has described Dreamforce to me as going to Summer camp, where you get to reunite with all the friends you haven’t seen for the past year. While this might not be the best way to convince your boss to let you attend this conference-to-end-all-conferences, it does highlight one of the most valuable products Salesforce has to offer: the community.
Yes, the hands-on-training sessions are great learning tools, and the keynotes are always an exciting look at what’s coming up in future product releases. But when you’re back at your office, sitting in front of your computer, baffled by the Process Builder that keeps inexplicably failing, who’s going to help you?
Answer: all those friends you see every year at Dreamforce.
Whether you post your question in the Success Community, Developer Forum, Power of US Hub, or call in to one of the dozens of office hours hosted by Salesforce users like you, you have a wealth of access to people who’ve stared at that same Process Builder and want to help you be successful.
So go ahead, give us your toughest questions, your seemingly insurmountable Salesforce challenges. We’ve got a community of thousands that wants to help you #LevelUp.
[fusion_builder_container hundred_percent="yes" overflow="visible"][fusion_builder_row][fusion_builder_column type="1_1" background_position="left top" background_color="" border_size="" border_color="" border_style="solid" spacing="yes" background_image="" background_repeat="no-repeat" padding="" margin_top="0px" margin_bottom="0px" class="" id="" animation_type="" animation_speed="0.3" animation_direction="left" hide_on_mobile="no" center_content="no" min_height="none"] Among the tips that Bryan Rees at InCadence posts in a blog about Architecting for the Cloud, he highlights the importance of solving for all requirements in a whole solution instead of thinking of requirements as a silo. We do this by grouping requirements together and solving them in groups. The way he puts it is:
Architect your solution in a componentized way: The key to being a cloud architect is to step away from the mindset of trying to crank through all the functional requirements by yourself. One has to step back and think about the business requirements and then architect a solution of loosely coupled components that address the overall requirements. This takes a bit more work upfront but pays huge dividends later, not only in terms of executing on the initial project but also for maintaining and evolving your solution.
A(n overly-)simple way to think of this is a scenario where a custom field will solve an immediate need. The temptation is to just create the custom field and move on; however, if the field is representative of a list of items, then, in order to accomplish the list, a custom field must be created for each option on the list. That line of development will leave an organization with 15 fields on a page instead of one picklist or custom object. Since the fields can't really be combined well into a report to get onto a dashboard, the organization then exports to Excel in order to share it with the executive who needs to see it.
The article is worth the read his next point about API's over language and his later comments on crowdsourced solutions are also worth a read.[/fusion_builder_column][/fusion_builder_row][/fusion_builder_container]