Last week the team released a number of updates and bugfixes, but the biggest yields from their work will be unveiled tomorrow when we release the beta of Zapier, beta of Webhooks and upgrades to the Requests module. Keep an eye on our Blog for more information.
The Bulk Client Invoice screen is one of the most popular features of our major Invoice Upgrade from a couple of months ago, but one thing our first "search and filter screen" was missing was the total amount of money that the matched/filtered work was going to invoice for.
The reason we missed this in the main upgrade was down to complexity - calculating the number of projects, tickets and retainer periods that matched the filter/template criteria was hard enough, and at the time of the upgrade then going through and calculating the rates and prices of what should be invoiced was another order of magnitude on the difficulty scale.
With a bit of room to breathe after the upgrade, the team have been able to sharpen their pencils and have done a bunch of work to optimize the queries and the searching patterns to now allow you to see how much money you're going to invoice for in the Bulk Client Invoice process. While the bulk invoice wizard is a lot faster and easier than invoicing was previously in Accelo (or any other product we're told), there's nothing quite like seeing the financial benefit of spending that time doing the billing work to make it all worthwhile!
Accelo’s Campaigns module allows you to customize a list of targets (email recipients) drawing from all of the contacts stored in Accelo. For those with a Mailchimp account, rather than composing and sending from Accelo, you can link Mailchimp to Accelo allowing you to push Accelo’s target list to Mailchimp - where the actual delivery of each email takes place. As recipients start opening and clicking on links in the emails, Mailchimp will track these statistics, and as part of our integration, these statistics can be sync’d into the campaign in Accelo. The issues we’ve recently resolved here include:
Linking Open, Click and other behaviors on the right campaign action
The problem was that when the updates came in, we identified the target by email address only. So if a given target (eg email@example.com) was a member of multiple campaign actions (which is a very valid use case) then only the first campaign action he was associated with would be updated.
Falling back to your colleague's API key if you didn't connect to MailChimp yourself
MailChimp's API uses oAuth tied to an individual user, which in turn requires every user who wants to use/view statistics to login and authenticate with MailChimp directly from Accelo. While this makes total sense for things like sending emails out (you don't want the intern in accounts to be able to send a blast out to all of your users on your behalf), for viewing read-only data like statistics (for users who have the permission in Accelo) we thought that locking someone out just because they didn't do their own MailChimp oAuth dance was a bit restrictive. Now we'll try and use the current user's credentials, but if they don't have their own we'll try and use another user's key just for this act of viewing and refreshing statistics.
When you send an email and copy and paste in an image, it gets sent by your email client as an inline image and attached without a filename. Accelo is able to capture and store most of these attachments, however we had a situation where emails sent by particular email clients were being "embedded" in a way that we didn't recognize as an attachment. (The technical reason is because their Content-Disposition contained more than the word "Attachment", and also contained info like their last modified timestamp, etc).
We've now made the capturing process more robust and we're capturing these images now.
Our team have made some awesome changes under-the-hood with our Triggers & Alerts functionality, allowing many types of triggers to fire the instant their rules are met - rather than being added to the queue that fires every 15 minutes.
While we only know of a couple of customers who ran into this problem, we wanted to flag it just incase other customers notice some vagrant invoices failing to sync with their accounting system.
Since our recent invoicing upgrade, the way our system was internally representing floating point numbers (basically very long decimals for the non-techies reading this) meant that, in rare instances, a rounding error could occur. Fortunately the accounting systems we integrate with were able to detect this and we’re now handling these cases consistently.
When you need to relocate an email/conversation to work under a different client, the Contributor feature is your answer. The contact involved in the email just needs to be added as a contributor on the object (e.g. project) where the conversation needs to be relocated. Then when using Accelo’s relocate tool, that object will become available for selection.
However, the quirk that our team addressed last week relates specifically to the inline relocate tool; while the object became available for selection, any tasks for that object were failing to appear.
Accelo has a powerful user permission set in additional to the 4 user access levels - Admin, Professional, Collaborator & Contractor. There are some features and operations which are intentionally excluded for certain levels, like not allowing Contractors and Collaborators to create invoices because of the sensitive operations of managing financial data, and around how Contractors appear in communications with a client (their email address is always obscured - since they're quite possibly coming from an @gmail.com address and you want to make sure the client relationship keeps going through the business).
However in this case it was discovered that an access-level restriction was placed on the relatively simple operation of changing a contract/retainer status. This has been corrected so now if a Collaborator user needs to “progress” the status of a retainer, it can be accomplished - provided they have the appropriate user permission enabled.
Clients, Sales, Tasks, Tickets - nearly everything you can create/view in Accelo can also be tagged. Tags help you quickly add extra detail for categorizing your records, and also make records more searchable. We also realized that tags are useful when working with your data outside of Accelo - whether it be an export of Tickets, Task or Projects. Now when exporting records from any List screen, you’ll find the Tag information added in the final spreadsheet column.
While most Accelo users will record payments in their accounting system (and allow the payment details to sync back to Accelo), it is possible to record payment on an invoice directly in Accelo.
This process includes a checkbox option to “Send Receipt Via Email”, so you can easily notify the customer that their payment has been recorded. We had a temporary problem with this feature but can confirm that the sending of receipts is working again.
While Contract Types don't change that often, we've had a request from a developer in our Developer Mailing List - if you're a developer, you should join at https://groups.google.com/forum/#!forum/accelo-devs - for the ability to pull a list of Contract Types.
While it took a little while for one of our engineers to get some clear air, the team have now extended the API to support Contract Types - you can now perform a GET on /contracts/types, /contracts/types/:type_id and /contracts/types/count endpoints. Note that you can't create Contract Types via the API at the moment - they're just too complicated with too many dependencies and validation steps to support via the API right now.
Speaking of API documentation, we're working internally on giving it a refresh in the next few weeks; we've sneakily added some cool stuff to it over the last few months.
We've had a particularly hard to track down bug biting our users very occasionally over the last few months where emails would sometimes have files attached which have zero bytes.
It turns out this was happening in part because of performance improvements we'd made to Accelo - in short, we were processing emails too quickly and in a parallel, auto-scaling way, and this meant that we would sometimes process an email coming into multiple people (and/or a request queue) at the same time. When these emails had decently sized attachments, the act of saving them would cause processing for one of the emails to slow down (as you'd expect), and the other emails would "race ahead". At the end of processing, we'd then do a check to make sure we hadn't processed the emails in parallel, and if we had, we'd remove the offending duplicate.
Before we applied this bugfix, we were also incorrectly removing the attachments of the duplicated email, which meant that the immediately following processes were saving the file with 0 file size. Thankfully, we've now fixed this bug!