The Contact merge interface does not show first/middle/last names as separate columns. When you have multiple contacts that only differ in that one of their names is actually a double name, e.g., John David as first name instead of John as first name and David as middle name, the two contacts appear identical in the Merge interface, so you don't know which one you are picking as the primary contact....
Can this be fixed?
@mike_appcoll Just curious--any ETA on item (c) above?
AppColl allows you to have logins to multiple AppColl accounts, allowing a law firm user to access the law firm's AppColl account and also client AppColl accounts (if given login rights). It's a neat feature.
Right now, to switch accounts you have to go to the account icon in the upper right corner, hover over it, hover over the Switch Accounts menu flyout, and then select the account you want to switch to. You then need to navigate to the matter you want to view in the switched-to account.
In many cases, a user will actually be wanting to switch between accounts to look at the same matter. For example, there may be tasks that need to be completed in two separate accounts for the same matter. It would be a really neat feature if AppColl could, for users having login rights to multiple accounts, identify those matters that exist in two different accounts and then, in the Matter Details view, provide a button that, when clicked, switches between the record for that matter in one AppColl account to the record for that same matter in the other AppColl account. This would let the user flip back and forth between two accounts while still viewing the same matter. This saves the user the hassle of navigating back to that matter in either account after an account switch (and avoids the need to use the Account Switch flyout menu.
I'd like to suggest a new deadline type: "Workflow." Workflow deadlines would be similar to "internal," but would have the ability to be caused to not be displayed in the Matter Details interface if completed (while still displaying other completed deadline types). Tasks with Workflow DeadlineTypes could also be turned on/off wholesale in the Matter Details interface, similar to "Internal" and "USPTO" tasks.
Tasks with Workflow DeadlineType would also be able to be edited by anyone regardless of their permission level.
The idea would be that users could use tasks with this DeadlineType to track various workflow stages, e.g., reported out to client, recommendation sent, response drafted, etc., and then close them out, thereby allowing workflow to be tracked internally. However, external deadlines and events would not be able to be edited except by users with Tasks edit permissions. This allows customers to tightly control access to mission-critical data, e.g., docket and bibliographic data, to their docketing departments while also allowing them to track workflow progress without needing to involve/burden their docketing departments.
Having the ability to screen out completed workflow tasks would allow fairly granular workflows without cluttering the Matter Details task interface with lots of completed workflow tasks....
@support_appcoll Has there been any movement on implementing this idea? It would be hugely useful to have the ability to define some custom fields for tasks.
For example, a field for "In IDS Database" to record whether an Office Action and its cited references have been added to the IDS database. Or "recommendation sent" to indicate that the client has been provided with a recommendation.
Christian
When filtering Matters, it is not possible to select the PatentTermAdjustment as a filter condition. Can this be added?
How does AppColl handle it when it receives an email sent to the intake.appcoll.com domain that does not match any matter? I just deliberately sent a message to an incorrect intake address to see if it would bounce back, and so far, nothing's happening.
We are considering using the new intake address format for emails to clients that use AppColl, but the risk is that sometimes clients change their AttorneyRefs without telling us, resulting in our ClientRef not matching their AttorneyRef until the discrepancy is noticed and corrected. If we then generate and send an email to the client-side email intake address based on our firm-side (ClientRef) version of their AttorneyRef, it will not have a valid intake email address.
If an email sent to the intake address turns out to not be able to be matched to any AppColl matter for the specified customer account, it would be great if AppColl could send an email back to the sender alerting them to the issue--that would a) let them know that the email didn't get saved and b) prompt them to investigate and correct the issue that caused the problem....
Can this be done?
Just checking on whether there's been any movement on this suggestion--it was made nearly a year ago, and the interface is unchanged. This seems like a relatively easy fix to make, and would be a nice quality-of-life enhancement....
Best,
Christian
@BruceY9495 I'm curious as well--it was supposed to have been instituted end of last week.
For the official filing date field, have you been manually updating it with the EBD all these years? I can't recall if it auto-populates, but if it does, it's only doing it for national stage applications.
If you have, good foresight!
@gregg_appcoll Hi Gregg, do you know when the EBD field will be populated with data for all our existing US matters? The field is there, but not very useful to us without that info...would rather not have to add it all manually.
It would be helpful if Matter records had a yes/no field for POA that could be used to indicate if a power of attorney had been accepted for a matter. For example, this can be very helpful when transferring matters in and in identifying cases where a power of attorney has been filed but not yet accepted....
Even better would be if it could automatically determine yes/no status of this field. Not sure if that's possible though.
The browser-based email editor included in AppColl automatically inserts the matter AppCollEmailIntake email address into the recipient list for any email created in it. It does this even if the AppCollEmailIntake email address is not included in the email template that is used to generate the email.
Can this please be fixed? We do not use the EmailIntakeAddress for our own account but do use it for clients that have AppColl and wish us to use their version of it, and it can cause confusion when both are present.
The whole point of having an email template is so that there can be a consistent format for emails, and having the editor decide to override the template and include recipients that aren't supposed to be there seems contrary to that purpose. If a template is intended to reference the EmailIntakeAddress, it is easy enough to include that field in the template--AppColl should not be inserting it on its own.
It would be nice if AppColl could provide a read-only field that was, in effect, a list of previous contacts that had a particular role with respect to a patent application, such as "Attorney" or "Paralegal." Sometimes, it becomes necessary to reassign matters to different individuals, e.g., due to someone leaving the firm or taking an extended leave (e.g., parental leave, sabbatical, etc.).
It would be nice to be able to filter matters based not just on who those matters presently list as attorney, paralegal, etc., but also who they previously listed in such roles. This could help with reversing those assignments at a later date if the previously assigned person returns to work at the firm.
For example, an "AttorneyHistory" field could store all attorneys that have been assigned to a matter, while ParalegalHistory could do the same for all paralegals that have been assigned to the matter. You could have ContributorHistory, PartnerHistory, and ClientContactHistory as well, but those likely aren't quite as immediately useful.
Otherwise, one has to either think ahead and export the previous assignments before updating them (so you can do a bulk reverse update if you want to restore the original assigned practitioner/paralegal) or parse through the Transaction History to identify all cases where the original assigned practitioner/paralegal was changed, and then craft a filter that identifies all of those matters by docket number (which could easily require multiple queries due to the filter string length limitations).
@BrandonK6644 You could very easily set up such task types--just use the existing ones as templates, update/rename them as needed, and start using them going forward instead of the vanilla Filed RCE. You'd have to manually select the appropriate one, of course.
Doing the same for OAs would be a little more challenging since they autodocket, but I think it could be done. You'd have to make some fancy database query triggers that would check to see if a prerequisite task (e.g., 1st OA) had docketed before triggering a 2nd OA task, and checking to make sure that no existing 2nd OA task was present. I think this can all be done in the current task framework--see example below.
First NFOA - Create "Respond to 1st Non-Final Office Action" task
When a specific task is created: "Receive non-final office action"
AND
While a task database query doesn't return any records: Matter = "{Task.Matter}" and TaskType.Contains("Respond to") and TaskType.Contains("Non-Final Office Action")
Second NFOA - Create "Respond to 2nd Non-Final Office Action" task
When a specific task is created: "Receive non-final office action"
AND
While a task database query returns one or more records: Matter = "{Task.Matter}" and TaskType = "Respond to 1st Non-Final Office Action"
AND
While a task database query doesn't return any records: Matter = "{Task.Matter}" and TaskType = "Respond to 2nd Non-Final Office Action"
And so forth for 3rd, 4th, etc. NFOAs (assuming you want that level of granularity).
NOTE: In order for this to work, the most recent previous NFOA task has to be correctly assigned since each subsequent task creation event looks for the "previous" task that should have been created according to the trigger rules. So you'd have to analyze your docket and at least update the most recent Respond to NFOA tasks to reflect their proper "number" before implementing the above rules.
As far as I know, there isn't a "While a task database query returns exactly X records" where you can specify X. If that existed, you could avoid having to back-update your tasks to the new format.
Cheers,
Christian