• Home
  • Forums
  • SBM
  • How do I stop the TeamTrack Login from appearing when users log in.
adeline su
adeline su
Offline
0
An organization is often divided into business units, which are composed of divisions. Divisions are composed of departments.

When I request, it needs my department manager to approval, and then approved by the division manager, and then approved by the business units manager.

What's the SBM best practices to maintain an organization's structure with user?
Responses (2)
  • Accepted Answer

    Thursday, December 27 2018, 06:15 PM - #Permalink
    0
    The answer depends on which version of SBM you're using: Older (before Workcenter) or newer.

    In older versions, there is the "Contacts" table (database name is "TS_CONTACTS"). This is an auxiliary table in the Global Process App. If you use Contacts, a User (User database record) can be associated with a Contact (Contact record) in the Add/Update User dialog. A Contact is usually associated back to a User but this is not necessary. The nice thing about the Contacts table is that, unlike the Users table, you can add fields to define additional attributes for a Contact. For example a Business Unit field, Division field and Department field. That allows you to pick a BU, Div and Dept for each Contact. Since a User record has a Contact record, those attributes apply to the User. You can create these attributes using single-selection fields and define the list of, for example Business Units, in Composer. However there's a couple drawbacks to using single-selection fields:

    1. If the names or list of Business Units, Divs or Depts ever changes, you will need to modify the fields in the Contacts table and re-deploy. If you have a strict change policy, it may take all kinds of meetings and change requests and managerial sign-offs to get even a simple change into the Production environment. Bring beer to those meetings ;) (just kidding!)
    2. Adding sub-attributes to a Business Unit, a "Manager" field for example, complicates the Contact record. If a Biz unit only has a manager, it's not too bad. If, however, Business Units, Divisions and Departments all have 10 or 20 additional attributes ..... you can see how complex the Contact table would start to get.

    In your application, because a Business Unit, Div and Dept all have additional attributes like a Manager, I would suggest creating an aux table for each. In each aux table you would have a "Name" and "Manager" field. Rename the "Title" field to "Business Unit" or "Business Unit Name" and add a "User" type field for the Manager. Perhaps you need additional "Business Unit-specific" attributes like "Manager's Administrative Assistant" or "Business Unit Web Site" or "Business Unit Main Office Address". Create the fields for those in that aux table. Back in the Contacts aux table, create a single-relational field that points to the "Business Units" aux table.
    Also, since a "Division" belongs to a "Business Unit", when you create the "Divisions" aux table, include a single-relational field called "Related BU" that references the "Business Units" aux table. Now you can select the "parent" BU for each Div.

    In your Workflow's Primary table, you can now add the "Contact" field. This will be set to the Contact record related to the Submitter field. Read the Composer Guide for some specifics on how this works. The gist is that the Contact field is only set in the Submit transition. If you change Submitter somewhere else in the Workflow, you'll have to keep the Contact field in sync yourself.
    If you don't have any experience with sub-relational fields, this is a good place to discover how they work. Add a sub-relational field to the "Divisions" aux table, related to the "Division" field and showing the "Division Manager" field.



    For newer versions, Workcenter includes the "Resources" sections under the Application Administrator. This is a 90% implementation of what you described. I haven't personally done anything with the "Resources" stuff, or worked with a client who wanted it, so I don't have a lot of knowledge. You'll need to study the App Admin guide or on-line help.
    The advantage of using Resources is that it's "tied into" user accounts via Workcenter "Contact Cards" -- that's the thing that pops up when you click on a User name in a report or item. All that Business Unit / Division / Department / Manager information is instantly accessible to a user.

    The main difference I can see is that the SBM Resource stuff does not include a "Division" middle layer that you have. You might be able to implement that with an aux table. You'll need to check with MicroFocus support for how to do that or if it's even possible.

    One drawback to the SBM Resource implementation is the one-to-one relationship between Resources and Job Functions. I've seen too many instances where a user has to work several jobs. Sometimes due to cutbacks; sometimes because they're changing positions and still need to do their old job until someone else gets stuck with it hired and trained.

    Hope this helps.
    Like
    The reply is currently minimized Show
  • Accepted Answer

    adeline su
    adeline su
    Offline
    Monday, December 31 2018, 10:45 PM - #Permalink
    0
    Hi Paul,
    Thanks for your reply.

    I have tried adding "Resources" data, but not like the "Contacts" aux table, I did not create a single-relational field to points the "Resources".

    I can't find any way to use the "Resources" in my application.

    Adeline
    The reply is currently minimized Show
Your Reply

Recent Tweets