Preparing Production for Sys Admins and Developers

When performing configurations in Production, particularly workflow and screen changes, you will need to put a few things in place.

ASM's Role Based Access Security makes protecting Production from unintended consequences a snap to do and minimizes overall risk.

Audience: System Administrators/ASM Developers with sufficient rights to update, change, and configure ASM, ASM Screens, and ASM Workflows.

Before undertaking any development or System Admin activities in Production, please review the whole of the Best Practice Section.

To prepare Production for your developers and System Administrators to maintain ASM's Configurations you will need to complete this checklist at a minimum. More configuration may be needed based on your individual use case's:

Subscriber Group

Create a Subscriber Group, e.g., "ASM SYS ADMIN', or 'ASM DEV'

Access Menu>Search>Subscriber Groups. Create a subscriber group for your developers and add the correct individuals to it.

Why? You will use the Subscriber group for Service actions you want developers to see on the Portal, but not customers. Please note, you cannot link a service action to a subscriber group if it is available to all Users, that is, if the Available to all Users checkbox is selected. You will need to ensure for each Service action that only developers should see, you uncheck the Available to All Users checkbox.

See Also: Managing Subscriber Groups

See Also: Managing Service Actions

System Admin Settings/Security Settings

Update Security Profiles and Roles, e.g., update the ALL role and ensure all options are ticked and that the Sys Admin and Developers, at a minimum, have this role.

Access Menu>System Admin>System Administration. Here you will update the following:

1. System>Security Profiles: Create a security Profile for System Administrator, Developer, or similar.

   • Assign this to each person that will be doing development or System Administration and configuration in your Production system.

   • A security profile grants access to secured objects, notes, fields, actions and solutions.

   • See also: Setup Analyst Security Roles

2. System>Workflow Management>Workflow Processes: Setup a Workflow Process for developers to put workflows that are not ready for publication, e.g., 'Development'

   • Ensure the Developers Security Role has access to the Workflow Process.

3. Security>IPK Groups: Setup a Developers IPK Group and assign the email address for their DL, if desired.

   • Make sure to tick the "Email Analysts" and "Closure Group" box.

   • Set the correct Escalation Recipients.

   • Add each analyst to the group that will be performing development or System Admin is ASM.

   • See Also: IPK Groups

4. Security>Workflow Management Groups: Setup a Developers Workflow Group and assign the email address for their DL, if desired.

   • Make sure to tick the "Email Analysts" and "Approval Group" box.

   • Add each analyst to the group that will be performing development or System Admin in ASM.

   • Set the correct Escalation Recipients.

   • Set the Resource Management Stakeholders.

   • See Also: Managing Workflow Management Groups

5. Security Roles: Add a security role to each Role Type, or ensure the 'ALL' role has all available options enabled.

Why?

1. Security Profiles will allow you to create new fields and sections on existing screens and expose the new fields only to developers until such time as you are ready to make them visible.

2. Development Workflow Process. A dedicated development workflow process will prevent any one seeing or accessing a workflow that is not ready to be published. Think of it like a draft folder.

3. Developers IPK and Workflow Groups. You will want to assign all automated assignments and notifications to this groups so that as you build and unit test any notifications that leave ASM, go to your developers and not real customers. Of course, when its time to release the work, you will need to update your notifications and assignments.

4. Security Roles - the developers need to have access to the full depth and capability of ASM.

System Admin/Portal Settings

Create a Self-Service Portal System for assessing changes to the Portal Tables, Skins, Design, and Menus. Ensure developers understand how to make changes to and access it.

Update or Create Self Service Portal Roles to support these activities, e.g., you may need to create Developer Roles that mirror your user roles so they can see the effect their changes have by user type.

1. Self Service Portal>Self Service Portal Roles: Set up a role for developers, or update the 'ALL' role to include all available options.

1. Self Service Portal>Self Service Portal Systems: Create a production test portal where you can test changes without impacting the production portal.

   • e.g., changes to my options

   • e.g., changes to Home page, skin, or portal tables

   • Repeat for My Options and Portal Tables options.