Archive for the ‘Cross object Filters’ Category

Happy New Year from the Apsona Team

Wednesday, December 31st, 2014

As 2014 draws to a close, we thought you’d be happy to hear from the two Apsona elves that are hard at work creating new features to serve you better. So here are some features you might like.

  • The field selector for creating filters and for adding fields to reports is now easier to use as well as searchable for both objects and fields. You might look at the screen shots in our documentation, and better yet, try it out!
  • Administrators can now manage their Document and Mail merge licenses from within the Apsona application.
  • Document and Excel merge actions can now be invoked directly from either a detail page button or a Salesforce sidebar component, e.g., from the left side of your Salesforce home page. Visit our website for more information about this.
  • You can now generate address labels from the document merge tool.
  • As always, if you see bugs or glitches, or have questions or suggestions, please do not hesitate to contact us.

    Thank you for supporting the Apsona apps. Wish you the very best for 2015 and beyond.

    The Apsona team
    http://apsona.com/salesforcehttp://apsona.com/blog/happy-new-year-from-the-apsona-team/http://apsona.com/blog/happy-new-year-from-the-apsona-team/http://apsona.com/blog/happy-new-year-from-the-apsona-team/http://apsona.com/blog/happy-new-year-from-the-apsona-team/http://apsona.com/blog/happy-new-year-from-the-apsona-team/

    Managing file storage in your Salesforce Org

    Friday, February 21st, 2014

    Apsona for Salesforce now supports Attachments, Notes, Tasks and Events for all objects of Salesforce, native and custom. You can now import, export, update and delete data into these objects. So, why is this functionality different, when it is already supported for the existing native and custom objects? Apsona treats Attachments, Notes, Tasks and Events as linked to specific Salesforce objects. For example, the Contacts object in Apsona, has its own Contact Notes, Contact Attachments, Contact tasks and Contact Events objects. Similarly, any object that has associated Task records in Salesforce has its own “surrogate” Task object in Apsona. This is extremely handy as when you import notes or tasks to a contact – it is automatically linked to the contact. All you need to provide is the Contact ID or Full name during the import. Similarly, you can manage the Task records associated with any object simply by using its associated surrogate Task object in Apsona.

    With this functionality, the Apsona app is very useful to users for managing the organization’s file storage. Storage in Salesforce can be of two types – file and data. File storage includes files in attachments, the Documents tab, the Files tab, the File field, Salesforce CRM Content, Chatter (including user photos). The file storage limits for a Professional edition user is 612 MB, and for the Enterprise user, it is 2 GB. From what we have seen, Tasks and Attachments use up the storage limit rapidly. You might choose to treat this data as obsolete after a few years, and wish to delete it. The System Administrator can take stock of all the attachments, documents and archived tasks as they all count against storage. With the surrogate objects in Apsona, searching and filtering data to be deleted can be achieved with a few clicks. For example, let’s say you want to delete Contact tasks which are 3 years or older. Isolating such data from the Activities table in Salesforce – a single table which has all the tasks of all the objects in Salesforce can be very tedious. With Apsona, this task is simple, easy and quick. Here is how you would go about it:

    • Go to Settings – Configurations, and bring the Contact Tasks object to the menu bar as described here.
    • Create a filter by created date and user.
    • Click Tools – Delete All
    • Done!

    You can now comb through each object for their Notes, Attachments, Tasks and Events, and free up a lot of used storage place, thus cutting down your costs.

    Similarly you can manage your Documents too. A common use case with Documents is when a user leaves the organization and you want to transfer ownership to another user. You can do this with easily with Apsona. Get the Documents to the menu bar. Run a filter by author name. Click Tools – Update All. When you choose the Author field all the users in the org will dropdown as values. Select the user and click Update All. All the Documents will now have the new owner as the author.

    These are just a few use cases we have covered in this blog. We hope you find this functionality useful and we would love to hear about your use cases. If you have not installed Apsona for Salesforce, do download it from the AppExchange and try it out.

    Searching across a chain of objects in Salesforce

    Saturday, December 28th, 2013

    Salesforce users often need to search for data records in one object that depend on conditions in a related object. Frequently, the dependency carries over to multiple related objects, or to chains of such relationships. For example, suppose you need to find all the Campaigns that have targeted the contacts from your Partner accounts. To retrieve those Campaign records, your primary search condition is imposed on the Account object (looking for Partner accounts). Having found those accounts, you must find the Contacts in those accounts, and then the Campaign Member records of those Contacts, and finally the Campaigns to which those member records refer. Thus we have a four-object chain of dependencies that must be traversed to produce the results you need.

    Such a query is not very easily constructed in native Salesforce. But Apsona for Salesforce provides the tools you need to solve problems like this. The way Apsona solves the problem is by repeatedly applying the idea of a filter, to produce what is called a nested filter, as follows. A filter is simply a name given to a specific search condition, associated with a specific object. For example, you can create a filter on the Account object, that asks for Account Type matching Partner, and name it Partner Accounts. You can then apply this filter in the Contact object, since the Contact is related to (actually, a child of) the Account object. When doing so, you would retrieve the Contacts of your Partner accounts, and you would use the Partner Accounts filter as a nested filter. You have thus carried a search condition on the Account object over to the related Contact object. You can then repeat this step over the entire chain of objects, thus producing the result you want. See the diagram below, showing the relationships among these objects.

    Here is the series of steps to produce your results:

    1. Start with the “primary” object that drives the filter condition. In this case, it is the Account object, since we start with the condition derived from partner accounts. Create a filter on the Account object, identifying your Partner Accounts. You can do this either in the console view (list-and-detail) or in the tabular views in Apsona. Save it with the name “Partner Accounts.”
    2. Create a filter on the Contact object. In doing so, if you open the Account panel of the filter builder, and select the record id field of the Account object, you will see the “in filter” option available. Select that option, and then select the “Partner Accounts” filter. Save this filter with the name “Contacts from Partner Accounts.”
    3. Create a filter on the Campaign Member object, using the Contact filter created in step 2, in the same way.
    4. Finally, create a filter on the Campaign object using the Campaign member filter from step 3.

    What we did here was make a filter on the primary object, namely Account, and applied the filter to the related object namely Contact. You can repeat this process as many times as you want, thus carrying filter conditions across a chain of relationships. We use the term nested filter to refer to a filter that uses another filter within it, in this manner.

    Searches, filters and reports in Apsona work across the board whether it is retrieve data for campaign management, sales management or case management. Apsona for Salesforce can be downloaded from our AppExchange listing for a 30 day free trial, and works with all editions of Salesforce.

    Thank-you Letters with Apsona’s Document Merge

    Friday, August 30th, 2013

    Thank-you appreciation letters by snail mail are the lifeblood of  nonprofit organizations. The donor needs to be convinced that he/she has made a  right investment and the donation will be used wisely. Appreciation letters need to be sent not only after every donation, but also once or twice a year. Personalizing the letters is key to a positive experience, but when this has to be repeated to hundreds of users, it is a major challenge to small/medium non profit organizations. The cost and effort of producing such personalized letters several times a year can be rather daunting.

    Apsona’s Document Merge add-on for Apsona for Salesforce is exactly what is needed in these cases.  Users can build flexible templates that can contain multiple fields drawn from multiple objects – Contact, Donations and so on. Aggregate fields and sub lists can also be included in the template.  Fields names in the template and in the tables can be adhoc and need not be exact matches to the field names in Salesforce or in the reports. What Apsona brings is the utter simplicity and flexibility of the entire process for the template builder. Apsona’s  DocMerge will produce  a single or batch of .docx document files from a .docx template and the results can be downloaded either as a.zip file  or as a single .docx file with many pages, one for each record and print them.

    Here is the simple step by step process.

    1. A thank you letter will typically have top level merge fields from the Contacts object like the name and address. When creating this letter template in Microsoft Word, create merge fields with the usual Quick parts – Field – merge field. You can also Apsona’s macro to build quick merge fields, and that is definitely a time saver and less tedious (our humble opinion).
    2. Next, if you need to include a list of donations to the contact, you build tables. Tables are very easily created. The leftmost cell in the table should include the TableStart field, which specifies a record group name following a colon. For example, for the tag TableStart:Donation, the suffix Donation will be the name of the record group for the table. This name is just a mnemonic indicating the kind of list being produced. You can make up any name you want, as long as it does not conflict with any other merge field name in the document. The rightmost cell in the table should similarly include the TableEnd field. These two markers indicate the region of the document that must be replicated, once for each Donation.

    3. The data source for a template can be obtained from pre-built Apsona reports, or directly from an object. For example, in a single template data for a list of donations can be obtained from a Donation report and data for a list of  in-kind donations can be got directly from the Assets object. Before running a pre-built merge template, you can also apply additional filter terms on the fly if required.

    That’s it — system administrators can set up templates and its data sources, and all that the end user has to do is run an existing merge action whenever the need arises.

    Apsona’s merge tool also supports Excel merge and email merge. For a more details on these features please visit our product description page.

    Filters in Apsona – Part 1

    Wednesday, July 31st, 2013

    Searching or querying of data is a very common need for Salesforce users. The required data that drives the filtering frequently does not reside in just one object, but rather in several related objects. For example, you might want to find Contact records whose Accounts are in a particular city, so that even though the data sought is Contact data, the filtering condition is on the related Account. And once you have figured out all the filtering conditions you want to apply, and retrieved the data you want, you would want to save the search, so that you can reuse it later.  Apsona for Salesforce offers powerful search and filter capabilities for all Salesforce objects, both native and custom, out of the box. All searches can be “cross-object” in the sense that you can look for records of one type based on conditions enforced by records of a related type.

    A query/filter can be built in two ways from the Apsona user interface.

    The first one is by clicking Search and More options, and the second is by clicking the filter dropdown and selecting New filter as seen in the screen shot above.

    The same filter editor opens up with both options, and here is where you will specify the search terms. When you click the drop-down to specify search terms, you will see a list of panels, one for each object. Each panel is labeled with the object name, and contains the fields for that object. The object at the top of the list is the one from which you are running the filter, with all its fields. Below that panel will appear all its related objects (and all their fields) which are one step away – basically the children and parents of that object. Note that one panel appears not just for each related object, but rather for each relationship. For instance, in the screen shot above, the Account object contains two lookup fields, Master Record and Parent Account, both referring to the Account object, so you see a panel corresponding to each.

    If the current object is the parent in the relationship, you will see an asterisk next to the name. In the above screen shot, the Contact or Lead panels both have asterisks shown, since the Account object is a parent of each of those objects. But if the current object is a child in the relationship (as in the case of the Master Record and Parent  Account relationships), no asterisk is shown.

    When running a filter in a one to many relationship, you can run a Quantified search. In this search, you look for records of one type such that all related records of a related type meet a certain condition, e.g., contact records for which all related tasks have a “completed” status. This search is called quantified because it uses the quantifiers all or none for related records. Let’s take an example where we want to find Accounts whose contacts have the salutation of Dr. (Doctor). We run a search from the Accounts object. For the search terms, we select the field “Salutation” from the Contacts table. Since the field is a picklist we get the option of choosing is among as one of the field operators. For the quantifier, let us choose the option for all records. Click search. We now get all the Accounts whose contacts have the salutation Dr. Notice that the returned list might include Accounts which have NO contacts in them. This is because an Account with no contacts satisfies – albeit vacuously – the requirement that all its contacts have a salutation of Dr.  Since we selected the quantifier as “all records”, Accounts with no contacts are also entitled to qualify.

    This is just one option of the 3 options available in the quantified search. The” no records” and the “atleast for one record” are equally powerful and will be touched upon in the coming blogs.

    You can try out these searches and more by downloading Apsona for Salesforce from the AppExchange.

    Updating Data With Inline Edit

    Friday, February 8th, 2013

    Apsona’s inline edit feature is gaining a lot of interest from large enterprises. A key reason is that  it  helps the sales rep to be more productive. A sales rep’s primary goal is, of course, to close deals. Whilst the sales rep spends a lot of time talking to customers, listening to their needs and tailoring the sale, he also needs to document and update all his interactions.  Apsona makes this data updating quick and easy.
    If you have used Salesforce for any length of time, you know that if an object has record types associated with it, you cannot use inline edit on any of its views. So if you are a sales rep who needs to update a bunch of opportunities, you have to first find them in a view, click each of them in turn, edit and save them, and reopen the view. So each update needs four page refreshes, not counting the actual clicks for editing.
    In Apsona, you can just select the Opportunities tabular view. The tabular view resembles an excel worksheet where all records are laid out in rows. Each field value is in a cell which he can click and edit. You can work on several fields in the same opportunity or in different opportunities, and when done, click save. You can invoke pre-built filters at any time to narrow down the list, and then make changes and save the records. You can also build cross object filters on the fly, search for certain data records and make changes without losing context. For example, when working with opportunities, you can select not only Opportunity fields but also fields from any other object related via a lookup or master-detail relationship in either direction (parent or child).
    Large enterprises use Apsona tabular views as top level pages. Salesforce admins build Opportunities tabular views with just the fields the sales rep requires to see.  Filters are also pre-built for the reps. So now, the rep need only select a filter, make changes to the records and click save. Thus he ends up saving a lot of valuable time.
    This is just one example of how inline editing is being used. This feature works across all Salesforce objects, native and custom, in Apsona for Salesforce. If you have not tried out Apsona, please get our free trial from the Salesforce AppExchange.


    Looking back, looking forward – 2012 in review

    Wednesday, December 26th, 2012

    It is December 2012 and the holiday season is in full swing. With all your good wishes we at Apsona will continue to thrive and support you all to the best we can. We are committed to bringing you more features and functionality in 2013. We are always willing to listen to your needs and requirements. Please feel free to contact us at any time. Thank you for taking the time to leave us reviews. Right now, we have over a 120+ reviews. We appreciate them immensely and they help us get along.

    This year has been an eventful one for us. We began offering Apsona for Salesforce in 2011, and had a few tens of users. By the end of 2012, we have close to a thousand users from a few hundred organizations actively using it. This year also saw us through the initial development of Apsona Multi-step Reporting, which our users have been very positive about. It has also been a year that has initiated very fruitful partnerships. We are delighted to work with our friends at Cloud for Good, an effort which has resulted in Over the Edge, a migration tool for moving from Raiser’s Edge to Salesforce.

    Whilst you told us that you liked what you see in Apsona overall, you have also asked for several cleanups and feature enhancements. We are very grateful for that feedback – many of the features currently in Apsona owe their existence to user comments.  Here are a few common user requests that we expect to see available in the coming months.

    • Improved reporting features, including the ability to show Apsona reports in Salesforce dashboards.
    • Automated periodic import and export of data, e.g., importing a data set from a file or an XML feed automatically into your Salesforce org every morning at 6 am.
    • Document merging, enabling you to merge a filtered list or a report into a Word or Excel document.

    If there are other features you would like to see incorporated in the products, please drop us a note.

    We would like to take this opportunity to thank all our users. We wish you all a happy, safe, healthy and prosperous 2013. Till we meet again for a new blog post in 2013 we leave you with a few of the reviews ( picked out in no particular order).

    Judi Sohn – An outstanding addition to Apsona
    Apsona is already a fantastic tool for data manipulation. No worries whether the user is using Mac or PC or whether they’ve installed a separate application. It’s all right there in Salesforce. The new multi-step reporting add-on is must-have. No having to start over if you want to add an additional object to a report, and you can select from objects related as either parent or child. No cleaning up in Excel either, as the result is just clean data. Excellent support.

    Robert Pope – Great app, easy to use
    We love this app – offers an easy to use interface and let’s us do mass updates and imports with ease – much easier to use than the built in Salesforce import tools! Thanks for an app that rocks 🙂

    Reede Stockton – Tremendous app!
    This is one of the most useful tools around. It truly shines when you need to do ad hoc reporting with unusual selection criteria. The ability to do cross object reporting and filtering makes it a breeze to tackle even tough requirements. If you’re a Salesforce admin, you’ll love Apsona. And it will quickly become apparent to you that, by pushing it out to your users, you’ll be able to quickly and easily fulfill a bunch of the requests that are cluttering up your to do list.

    John Schulte – Absolutely the best app!
    We also reviewed Apsona during a user group meeting and found it extremely user friendly and easier to use than other utilities of its kind. I actually prefer searching our Salesforce platform from Apsona since I get the data I am looking for the first time. It is much more accurate than Salesforce’s search options. We installed it in the Sandbox first but soon found out how accurate it was and installed it in production shortly after testing in the Sandbox. I use Apsona every day now and am totally impressed at how easy mass updates are now. Their help desk and videos are second to none!

    John Thew – APSONA IS FANTASTIC!!!
    Our SFDC consultant turned us on to Apsona and we are thrilled. This is absolutely the best app for mass importing information into SFDC that I have encountered. Easy to use and the staff at Apsona could not be friendlier or more helpful. SFDC should make this tool a standard part of the administrator’s package for their program.

    Happy Holidays!

    Cross Object Reporting For Salesforce Users

    Wednesday, November 28th, 2012

    We are very happy to see that our new offering on the AppExchange, Apsona Multi-Step Reporting (MSR), is attracting a good deal of interest. Users seem to enjoy the flexibility that the app offers. It imposes no restrictions on how to access objects, nor the number of objects you can access in a single report. It lets you traverse dependencies in either direction (parent-to-child or child-to-parent), and can handle multiple dependencies between the same pairs of objects. For example, you can create a report spanning the Campaign (parent) – Opportunity (child)-Opportunity Contact Role and back to up the chain to Contact (parent). Such structures are difficult to achieve with the native Salesforce reporting. Another plus with Apsona MSR is the ability to run reports without having to create report types.

    To help you build a report in Apsona MSR, here are a few tips:

    • Reports are built in steps.
    • Each step retrieves data from one object.
    • Each step carries its own filter conditions, independent of the other steps, and these conditions can be cross-object.
    • Steps are linked to previous steps via lookup fields.
    • To see linkages, select the id field or the look up field you would like to link in each step.

    You can build a powerful report incrementally in steps. You can have any number of steps in a single report. For example, let’s say you would like to invite to a Christmas luncheon all the contacts associated with the closed/won Opportunities or donations for the last 3 consecutive years, and you would like to retrieve the Contact records to set up the invitations. Here are the steps you can use to get the data with Apsona MSR.

      Step 1: Get the Contacts from the contact role object and filter by opportunities for the year 2010.
      Step 2:  Get the Contacts from the contact role object and filter by opportunities for the year 2011. Link the contacts to the Step 1.
      Step 3: Get the Contacts from the contact role object and filter by opportunities for the year 2012. Link the contacts to Step 1.
      Save and run.

      Another example use case is to find the person/user who created an opportunity and the person/user who closed the opportunity. Such a report can be obtained in just 2 steps with the Opportunity and Opportunity History objects. With Apsona’s cross object reporting, you can access the User object from the Opportunity and Opportunity History objects and pull in the users who have created and closed Opportunities. So here is an example of working from the Opportunity object down to the Opportunity History object and going up the chain to the User object. With an additional step you can also get the number of Opportunities (count) closed by a person/user by using the powerful metrics feature.

      Once the data for your report has been retrieved, you can visualize the data in charts, groups and matrices. Grouping can be single level or up to five levels. Pivoting or transposing data is a powerful visualization this app offers. Filtering, sorting, drilling-down and summarizing data can now be down in seconds.

      Such reports and pivot visualizations are not possible to build in native Salesforce and yet this information is invaluable to any organization. These are just a couple of examples of the kinds of reports you can build with Apsona MSR. You can now create reports to extract and display data instantly from your Salesforce org, without depending on others for coding or IT involvement.

      We offer a free trial of this app on the AppExchange and will be happy to help you if needed. We can be contacted at support@apsona.com.