CORE Security and Business Role Administration

Process Group/Policy/Procedure Details

• Title of Policy: CORE Security and Business Role Administration

• Effective Date: 07/01/2014 

• Approved/Revision Date: 01/4/2024

• Approved by: State Controller

Security Roles

Security roles control what CORE resources (documents, tables, and queries) a user may access and what actions the user may perform with respect to each resource.  All new roles or role modifications must be requested according to the established CORE Change Management Policy and be supported with a business justification.  Requests to add or modify security roles will be reviewed by CORE Operations subject matter experts (SMEs) for statewide impact and, as defined by the CORE Change Management Policy, may require approval from the CORE Governance Committee.  

Business Roles

Business Roles are new to CORE with the upgrade to Advantage 4.x.  The Business Role gives users a kind of short cut homepage view specific to the user's actual job role.  These Business Roles do not affect the security and workflow access or the actual Security Roles; they only visually present a homepage to specifically provide Quick Links and Widgets to help facilitate a user's job functions.

Creating a New Role 

When the need for a new role is identified, after the request has been submitted as a CORE Change Request, Functional and System Administration SMEs in CORE Operations will review the potential access and workflow impacts, and determine an overall solution configuration.  Considerations of a new security or business role will include if the request falls into one of the below categories:

• Leverage the system to its fullest capacity

• Standardization across the State – “create one, use many”

• Accountability through transparency

• Improve efficiency in business processes

• Provide reporting tools to assist in measuring and improving processes

• Strengthen internal controls

Evaluation of a new security role request will also consider:

• If the role will be a central role, departmental role, or both

  • If a department role, whether there is organizational security (e.g., security should be added so users can only affect the department codes that are under their department/cabinet code) 

• The code for each table, document, query to which the role needs access and the  type of access (e.g., update or approve)

• If the change will affect workflow (see the section in this policy related to workflow changes to ensure evaluation of those system components are completed)

CORE Operations will then provide a Change Advisory Board (CAB) narrative evaluation for the CORE Governance Committee to consider in their review of the request, as defined in the CORE Change Management Policy.  Any approved new security or business roles will be completed and tested according to established change management processes before being migrated into Production.

Once the new role is available in Production, a CORE Communication will be issued.  Users who require the new role will need to complete a new or update UDOC that is routed through existing approval processes in the system before they can use the new security role. 

Modifying an Existing Role

Modifications to an existing role include adding, modifying, or deleting the resources (documents, tables, or queries) assigned to a particular role or the actions the role may perform with respect to each resource.  Modifications may be identified through many sources – via stakeholder business evaluation, issue research in the system, as a submitted CORE Change Request, etc.  After the request has been submitted as a CORE Change Request, Functional and System Administration SMEs in CORE Operations will review the potential access and workflow impacts, and determine an overall solution configuration.  Considerations of a modification to an existing role will include:

• What are the modifications?

• Who currently has access to the role?

• How will the modifications affect the end users?

• Will the change pose any conflict to other documents that might write to the same table?

• If adding a resource, list each page code and: 

  • The roles that need access to the resource

  • The type of access each role will have to the resource (e.g., update or approve)

  • Whether access should be restricted by department (e.g., should security be added so users can only affect the department codes that are under their department/cabinet code).

  • Whether the ANY role can have access. Note: Justification must be provided and approved by the State Controller if the ANY role is not allowed access.

• If deleting a resource, list each page code and:

  • The roles that need to have access removed

  • If the access is moving from the current specified role to a different existing role 

  • If modifying the access a role has to a resource (e.g., adding field security or changing the actions that a user can take with the resource), list the page code and the type of access needed.

• If the change will affect workflow (see the section in this policy related to workflow changes to ensure evaluation of those system components are completed)

• What the impact is to existing reference tables, such as APGS, DCTRL, ADNT, AETDT, and any copy-forward functionality.

CORE Operations will then provide a CAB narrative evaluation for the CORE Governance Committee to consider in their review of the request, as defined in the CORE Change Management Policy.  Any approved changes to security or business roles will be completed and tested according to established change management processes before being migrated into Production.

Once the modified security role is available in Production, a CORE Communication will be issued.  Users who require the updated role will need to complete a new or update UDOC that is routed through existing approval processes in the system before they can use the modified role functionality.

Deleting an Existing Role

Deletion of existing security or business roles may be identified through many sources – via stakeholder business evaluation, issue research in the system, as a submitted CORE Change Request, etc.  After the request has been submitted as a CORE Change Request, Functional and System Administration SMEs in CORE Operations will review the potential access and workflow impacts, and determine an overall solution configuration.  Considerations of deletion of an existing role will include: 

• What are the modifications? 

• Who currently has access to the role? 

• How will the modifications affect the end users? 

• What role will have access to the resources under the current role once it is deleted?

• Will the change pose any conflict to other documents that might write to the same table?

• What will be the most effective way to remove the deleted role from existing users?

CORE Operations will then provide a CAB narrative evaluation for the CORE Governance Committee to consider in their review of the request, as defined in the CORE Change Management Policy.  Any approved deletion of security or business roles will be completed and tested according to established change management processes before being migrated into Production.

Once the deleted role has been modified appropriately to prevent future use in Production, a CORE Communication will be issued.