Best posts made by ChristianS2558

Currently, the syntax for fields in form letters is somewhat inconsistent--some of it is very straightforward, whereas other parts are not.

Taking ClientRef as an example, the basic syntax is: {Matter.ClientRef}. This is fine--very intuitive.

If you want to add characters before or after the field value that only show up when there is data for that field, however, you have to specify each such character using +XXX, where XXX is the 3-digit ASCII code. Thus, if you want a form letter to say "Client Ref.: <Field Value>" but to completely omit this text if there is no client ref, the field changes to:

{+067+108+105+101+110+116+032+082+101+102+046+058Matter.ClientRef}

A person editing this form letter later will have no idea what the text is that these numbers represent. It makes it very difficult to revise form letters that have enhanced form fields like this. It also makes such form fields insanely long in some cases--the appended or prepended text codes will be be 4X as long as the actual text that they represent.

However, if you want to specify alternate text to display in place of the field if the field is empty/null, then the syntax is quite straightforward:

{!No Client Ref Specified!Matter.ClientRef}

You just enclose the alternate text in exclamation marks and put it immediately after the opening curly bracket. A person reviewing the field immediately knows what it will say if there is no data in the field.

I would like to suggest that AppColl update the syntax for form letter fields to also allow for text that is to be prepended and/or appended to a field value to be presented as either the +XXX format, as normal text, or as a mixture of the two. This seems like it would be relatively easy to implement, as you could have a routine that inspects the prepend/append clauses for non-+XXX values and then does a substitution to turn any such values into +XXX format for processing by AppColl's current algorithm.

It would be helpful if Task Types had a setting allowing them to be specified as being "under development." Under-development tasks would only be visible to Admins in the GUI and reports and invisible to all other users. This would prevent such task types from inadvertently being used by users before they are finalized, potentially resulting in mis-docketed tasks.

Once under-development task types are finalized and tested, the "under development" setting could be removed and the task types made available for general use.

@SadiqA2304 I thought of that but was concerned that it might muck with triggering conditions if the task name was later changed to remove the "under development" text.

It would also mean that normal users would still see it and the under development tasks would still clutter up the interface.

@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).

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?

This relates to earlier posts I made: (https://forum.appcoll.com/topic/137/new-field-syntax-list?_=1773350339170) and https://forum.appcoll.com/topic/169/more-streamlined-form-letter-field-syntax?_=1773350545712

Having just had to update our Inventor/Applicant sheet, which is 9600 characters long and, in essence, just lists the first, last, and middle name, citizenship, address, and foreign nickname for the first 20 inventors, I thought it worth re-elevating this request. I wanted to add, for each inventor, their TaxID number (if they have one listed). It is a painful document to edit. Here's what it looks like in raw form for the first 3 inventors:

{MATTER.INVENTOR1.LAST}{+032MATTER.INVENTOR1.SUFFIX}{+044+032Matter.Inventor1.First}{+032Matter.Inventor1.Middle}{+044+032+067+105+116+105+122+101+110+115+104+105+112+058+032Matter.Inventor1.CitizenshipFull}{+013+010+067+104+105+110+101+115+101+032+067+104+097+114+097+099+116+101+114+032+078+097+109+101+058+032Matter.Inventor1.ForeignNickname}{+013+010Matter.Inventor1.Address}{+013+010MATTER.INVENTOR2.LAST}{+032MATTER.INVENTOR2.SUFFIX}{+044+032Matter.Inventor2.First}{+032Matter.Inventor2.Middle}{+044+032+067+105+116+105+122+101+110+115+104+105+112+058+032Matter.Inventor2.CitizenshipFull}{+013+010+067+104+105+110+101+115+101+032+067+104+097+114+097+099+116+101+114+032+078+097+109+101+058+032Matter.Inventor2.ForeignNickname}{+013+010Matter.Inventor2.Address}{+013+010MATTER.INVENTOR3.LAST}{+032MATTER.INVENTOR3.SUFFIX}{+044+032Matter.Inventor3.First}{+032Matter.Inventor3.Middle}{+044+032+067+105+116+105+122+101+110+115+104+105+112+058+032Matter.Inventor3.CitizenshipFull}{+013+010+067+104+105+110+101+115+101+032+067+104+097+114+097+099+116+101+114+032+078+097+109+101+058+032Matter.Inventor3.ForeignNickname}{+013+010Matter.Inventor3.Address}

The syntax for working with form fields leaves a lot to be desired. Things that would make it so much better/user-friendly include:

a) Ability to specify, in plain English, what the preamble/postamble for a given field will be. This business of spelling out, character-by-character, what the preamble/postamble should be using a + symbol and the 3-digit ASCII code for each character makes it impossible look at a form letter template document and understand how the document will look once populated with data. It also dramatically shortens the "usable" MailTo link content that can be passed to an email from an email template. Allowing use of plain English, e.g., with delimiters, would address both issues.

b) Ability to use "lists" in templates, e.g., if you have the same set of fields that you want to output for each member of a list, there should be a way to do that via a list field and one instance of the set of fields that you want to output, as opposed to having to specify the same set of fields 20 times with only an index number changing for each instance.

Separately from the above, it appears that the Address form field inserts a double carriage return at the end of it, thereby forcing a blank new line after it. This causes issues when Address is used in a block of other field data, like in the above example--each field in the block of field data has a +013+010 preamble that causes that field to start on a new line if data is present. If the field has no data, however, the new line doesn't get inserted, thereby avoiding a blank line. The Address field, however, doesn't seem to play well with this convention--I had to list it last for each block since it seemed it was always introducing an unwanted gap line in between itself and an immediately following field line. If users want a gap line after the Address field, they do always have the option of specifying one in the field postamble, of course.

Any chance that the above could be implemented?

Cheers,
Christian