Adding object to database, using linq or sql connection
As @ckuhn203 pointed out, the naming is pretty misleading, but it seems like your domain model calls that entity a Delegate. To dissipate ambiguity I'd call it something like DelegateEntity.

One convention in modeling, is to keep types singular, since an entity represents one single row in that tblDelegates table.

Now, in your insert code, the del instance is not needed. Leaves us with this (notice the name changes) - I'd recommend passing in your connection string to the context's constructor, instead of relying on the one in the designer:

    var context = new LinqToSqlDataContext(connectionString);
    var item = new tblDelegate
    {
        Pending = true,
        Manager_Alias = row.Cells[4].Text,
        Manager_Name = row.Cells[1].Text + " " + row.Cells[2].Text,
        Delegate_Alias = ADLookup.AD("alias"),
        Delegate_Name = ADLookup.AD("GivenName") + ADLookup.AD("sn"),
        Delegate_Email = ADLookup.AD("mail"),
        Created_User = ADLookup.ADCurrentUser(),
        Created_Dttm = DateTime.Now,
        Updated_User = ADLookup.ADCurrentUser(),
        Updated_Dttm = DateTime.Now // shouldn't this one be null?
    };

    context.tblDelegates.InsertOnSubmit(item);
    context.SubmitChanges();


A very important thing to keep in mind, is that a data context implements an interface called IDisposable, which means any instance of that type should be properly disposed, either by explicitly calling its .Dispose() method, or (the better way) by wrapping its usage inside a using block:

using (var context = new LinqToSqlDataContext())
{
    var item = new tblDelegate
    {
        Pending = true,
        Manager_Alias = row.Cells[4].Text,
        Manager_Name = row.Cells[1].Text + " " + row.Cells[2].Text,
        Delegate_Alias = ADLookup.AD("alias"),
        Delegate_Name = ADLookup.AD("GivenName") + ADLookup.AD("sn"),
        Delegate_Email = ADLookup.AD("mail"),
        Created_User = ADLookup.ADCurrentUser(),
        Created_Dttm = DateTime.Now,
        Updated_User = ADLookup.ADCurrentUser(),
        Updated_Dttm = DateTime.Now // shouldn't this one be null?
    };

    context.tblDelegates.InsertOnSubmit(item);
    context.SubmitChanges();
}


The context instance only exists within the using scope, and when the code exits that scope, context.Dispose() gets called, implicitly. Make it a habit to always put IDisposable instances in a using block.



Other than that, you're not following the naming convention for parameters: alllowercase is hard to read - should be camelCase:

public Delegates(bool pending, string managerAlias, string managerName, string delegateAlias, string delegateName, string delegateEmail)
{
    Pending = pending;
    ManagerAlias = managerAlias;
    ManagerName = managerName;
    DelegateAlias = delegateAlias;
    DelegateName = delegateName;
    DelegateEmail = delegateEmail;
}


But, instead of having a constructor with [potentially] dozens of parameters, you should simply remove all constructors (the parameterless one is there by default), and instantiate a Delegates like this instead:

var delegates = new Delegates { 
                                  Pending = true, 
                                  ManagerAlias = "foo",
                                  ManagerName = "bar",
                                  DelegateAlias = "_foo",
                                  DelegateName = "_bar",
                                  DelegateEmail = "foo@bar.com"
                              };


This syntax is the object initializer syntax - notice that you don't need to specify the () after new Delegates, because the syntax is calling the type's default constructor and the compiler knows this, so ()'s are redundant. Of course this syntax can't work if your type doesn't have a default, parameterless constructor.



If you have a linq-to-sql data context, you probably have a designer with a .dbml too; in there you can specify new, more C#-friendly names for tblDelegates and its columns, LINQ-to-SQL uses the read-only Source property to know which column it's referring to - this means you can have a table called SOME_UGLY_NAME in your SQL backend, and refer to it as SomeMuchBetterName in your C# code!

...this also means tblDelegates can be mapped to DelegateEntity ;)