[SalesForce] ERROR: SubscriberUpdateTrigger: System.LimitException: Too many future calls: 51

If you want to execute the same logic for 16 different fields then obviously it would be best to write the algorithm once. And in Salesforce bulking up any database reads and writes is important too. So one trigger that deals with multiple Accounts and handles all 16 fields would be ideal. Restructuring your code now is likely to avoid a lot of future pain.

To execute Apex logic in such a trigger, the get and put methods that take the field name string can be used:

List<Xyz__c> updates = new List<Xyz__c>();
Set<String> fields = new Set<String>{'UK_Rep__c', 'FR_Rep__c'', ...};
for (Account a : Trigger.new) {
    // Repeat algorithm for each of the 16 fields
    for (String field : fields) {
        Id repId = (Id) a.get(field);
        ...
    }
}
update updates;

And where you need the query to vary a lot, the query can be created as a string and executed as Dynamic SOQL. (Or sometimes just a where abc in :set may suffice.)

Also note that the sort of code shown immediately below is generally lethal (= governor limit exception). Fine with 10 Accounts where on average 10x10/2=50 times round the inner loop, but with 1,000 accounts its 1,000x1,000/2=500,000.

for(Account a:accounts){
    for(Account old : Accountsold)
    {
        if (old.id == a.id)
        {

Pass Trigger.oldMap into the class to remove the exponential factor:

for(Account a : accounts) {
    Account old : oldAccountsMap.get(a.Id);

Having read through your question and comments I still don't understand why @future is being used. What goes wrong if it is removed?

@Kevin C - The only way StackExchange is allowing me to reply is by editing your Answer. Again I apologize for not using the site as intended and will visit the help center when I have a moment.

First, thank you for your helpful response. To answer your question, the following scenario will occur if @future is removed. -If John D is the Account Owner and I attempt to add him to one of the Team Role fields on the Account then I receive an error. I do not have the exact error handy, but it is basically saying that I cannot perform the function because I am attempting to give John D lower permissions then what he already has. Due to him being the Account Owner he has 'Full'Access, but my code is trying to give him 'Read/Write'. I would be fine with 'Full Access' but the value is not available in Apex. @future allows the Account Owner to be added as a Team Member when adding him to the custom fields. Again, thank you for your response. Like I mentioned, I am VERY green when it comes to APEX and really trying to get a handle on it. I will take a closer look at what you provided and see if I can piece it all together.

Your change checking logic should collect a set of changed ids and then pass those ids in a single call to SyncContactsToUsers.sync. The double nested loop is not the appropriate way to do change checking and is one cause of your problems: instead have one loop and get the old values from Trigger.oldMap.

The replacement code would look like this:

trigger UserInsertUpdate on User (after insert, after update) { 
    if (Trigger.isInsert) {
        SyncContactsToUsers.sync(Trigger.newMap.keySet());
    } else if (Trigger.isUpdate) {
        Set<Id> userIds = new Set<Id>();
        for (User n : Trigger.new){
            User o = Trigger.oldMap.get(n.Id);
            if (n.isActive != o.isActive
                    || n.LastName != o.LastName
                    || n.Email != o.Email
                    || n.Phone != o.Phone
                    || n.True_Market_Name__c != o.True_Market_Name__c
                    ) {
                userIds.add(n.Id);
            }
        }
        if (userIds.size() > 0) {
            SyncContactsToUsers.sync(userIds);
        }
    }
}

PS

My mistake about @future not being allowed in the batch context. if simply dropping the use of @future altogether isn't possible, somehow presumably the logic also needs running in the batch case. Moving that responsibility out of the trigger makes sense. If not using @future in the batch case works then something like this could be done"

public class SyncContactsToUsers {

    public static void sync(Set<Id> userIds) {
        if (System.isBatch()) {
            syncNow(userIds);
        } else {
            syncInFuture(userIds);
        }
    }

    @future
    private static void syncInFuture(Set<Id> userIds) {
        syncNow(userIds);
    }

    private static void syncNow(Set<Id> userIds) {
        // Logic goes here
    }

    ...
}