TFNRegistry UI: Why does the MRO Create Cloned Templates and What are the Clean Up Rules?

The TFNRegistry will generate a clone (aka make a copy) of an existing Template Record when an Multi Resp Org Change (MRO) request has been submitted via the Automation Request Input (ARI) page and the following scenario has been met:

1. An MRO request has been sent from a Responsible Organization (Resp Org) to the TFNRegistry UI or API. Please Note: Whenever an Entity gains a new Template Record created by the Cloned Template process, TFNRegistry will automatically increment that Entity’s Template Allocation Limit (TAL) based on the count of cloned Templates gained.
2. The MRO function will check to see if the source Customer Record (CAD) (also known as a CR) is a Pointer Record (PAD) (also known as a PR) and if the Resp Org change crosses Entities. If yes to both of these conditions, the MRO function generates a cloned Template Name and then it will check to see if the cloned Template Name already exists.
   1. For Example: A Toll-Free Number is ported from Entity ZW to Entity ZA, and the source Template Name is *ZW123456, then the first clone of this Template Name will be *ZABR123456.
3. If the cloned Template Name does not exist, the MRO function will proceed to step 3A. However, if the cloned Template Name already exists, the MRO function will proceed to step 4 (skipping oversteps these steps).
   1. The Cloned Template process copies the source Template Record(s) to create a cloned Template Record(s) for the new Entity. Subsequently, the TFNRegistry via the MRO function will also save the source Template Name and Effective Date/Time with it in order for the TFNRegistry to know the Template Record it was cloned from.
   2. The MRO function copies the source Pointer Record(s) to the next 30 minute window and replaces the source Template Name on the Pointer Record with the cloned Template Name and changes the control Resp Org ID on the new Entity’s Pointer Record and then it will send a response to the Automation function.
   3. The TFNRegistry will send an MRO response to the Resp Org that initiated the MRO request after it has processed all Toll-Free Numbers in the MRO request.
4. If the cloned Template Name already exists, the Cloned Template process will compare the source Template Name and the Effective Date/Time of the source Pointer Record with the saved Template Name and Effective Date/Time of the cloned Template Record to see if they both match.
   1. If both Template Names match (i.e., source Template Record and target Cloned Template Record): The TFNRegistry will perform the same processes as described in steps 3B and 3C.
   2. However, if the Template Names do not match (i.e., source Template Record and target Cloned Template Record): The Cloned Template process will create the next cloned Template Name.
      1. For Example: If another Toll-Free Number is ported from Entity ZW to Entity ZA, and the source Template Name is *ZW123456 and it has a new Effective Date/Time (i.e. it was updated after the cloned Template *ZABR123456 was created), then a new cloned Template Record will be created and named *ZABR-123456. Subsequently, the last two steps listed in step 3 above will be performed.

The naming convention of the TFNRegistry generated (cloned) Template Names is documented below.

• When a Template is cloned, the “Updated By” field in the new Template Record for the new Entity will be set to the Login ID of the user who submitted the request.
• The Template Name field of the cloned Template Record will be set by the TFNRegistry to a new name based on the following naming convention: *%%BR$#########, where “%%” is replaced by the two-character Entity code of the new Entity, and “$” is described in the next bullet, and “#########” is replaced by up to nine characters that are copied from the source Template Name that appear in the 6th through 14th character positions of the source Template Name.
• The first clone of a specific Template Name does not populate the “$” character of the new Template Name of the cloned Template Record.
  • The “$” character is populated only when the TFNRegistry needs to create a 2nd or subsequent clones of the same Template Name. The only time the TFNRegistry needs to create a 2nd or subsequent clones of the same Template Name is when the Resp Org of the source Template Record has updated it after the TFNRegistry created the first clone of that Template Record.
    • If the TFNRegistry needs to create a 2nd or Nth cloned version of a source Template Name, the TFNRegistry will insert a single character into the 6th character position (identified as “$” as mentioned earlier) in the new Template Name.
    • The first time the “$” variable needs to be set, the TFNRegistry will set it to a dash “-”.
  • If the TFNRegistry needs to create a 3rd clone of the same source Template, the TFNRegistry will set the “$” variable to the letter “A” or the letter “B” for the 4th clone, and so on, or the letter “Z” for the 28th clone or the digit “1”  for the 29th clone, and so on.

Cloned Templates with MRO Cleanup Rules

The Cloned Template Records are removed from the Customer Record Database (CRDB) via an automated scheduler which occurs weekly on Mondays. The following provides the rules used by the TFNRegistry for removing the Cloned Templates:

1. The Cloned Template Record must not have any associated Pointer Records on it.
2. The Cloned Template Record must have the same Effective Date/Time as it originally had when it was initially created.
3. Cloned Template Records follow the same rules for Template Records unless otherwise noted in the steps listed above.