SugarCRM PowerHour w/ Jeff Bickart

2. Intro
• Power Hour
– Developer / Admin Resource
– Promote Successful Implementations
• Ticomix
– SugarCRM “Advanced” Partner
– 2014 Rising Star
– Consulting, Development & Support
– www.ticomixcrm.com
– @TicomixCRM / @TicomixInc
• Webinar Logistics

3. About Jeff Bickart
• Sugar Developer since version 4.0a
• Director of Engineering of a Voice-Enabled CRM
startup
• Chief Technology Officer, NEPO Systems − SugarCRM
GOLD Partner
• CRM Evangelist, Ticomix
• Contact Information
– @bickart
– www.linkedin.com/in/bickart

4. Development 101
• Directories of Interest
– custom
– cache
– data
– Modules
– include
– vendor
– sidecar
• Where do my changes belong?
– custom
– custom
– custom
– modules

5. Sugar Development 101
Agenda
• Teams
• Roles
• Role-Based Record View Layouts

6. Teams
• Team Management is used in Sugar to define permissions
and groupings for users. These permissions cover what
records a user is and is not able to access. Teams are used
in conjunction with Roles to form a robust security model for
non-admin users in Sugar. Users can use team settings on
specific records to allow different users within Sugar the
option to view these given records. Team settings can also be
used as a form of organization, thereby separating records to
be associated to specific teams for better tracking. Teams
can be based on departments, geographic regions, or
whatever else works best in a given organization.

7. Team Types
• The Global Team
– The Global team is created automatically when a Sugar instance is created. Global is the default team for
all new users, and every user is a member of the team by default. Global is a universal team, so any
records associated to the global team will be viewable by the users on this team. The global team is
intended to be available for all users and a shared team for all users in Sugar.
– Note: You cannot delete the Global team.
• Standard Teams
– Standard Teams can be created by administrators via Team Management. These are to be used
throughout Sugar to organize and grant access on organizational specifics to your organization. Standard
teams are often broken out into groups by departments, geographical regions, or duties. For example,
you may have an East and West team, and also a Sales and Support team.
• Private Teams
– For every user that is created in Sugar, a corresponding private team is automatically created in the
Teams module. By default, the private team name is the user's first and last name. A private team name
will be updated any time the corresponding user's profile is edited and re-saved, even if the change was
not made to the user's first or last name. For example, the private team for Jane Smith will be
automatically named "Jane Smith". If the administrator edits private team "Jane Smith" to "Jane Smith-
HR", and then user Jane Smith later updates the phone number on her user profile, Sugar will revert the
private team name back to the user's first and last name, "Jane Smith".
– If your organization plans to edit private team names, you must disable the automatic update feature.
Navigate to Admin > System Settings and select the checkbox next to "Prevent name changes by users
to update their Private Team Name".

8. Team Membership Types
• Team memberships are given to users in one of two ways, either by explicit or implicit membership. Regardless
of the type, membership will control what records regular users are able to see. Each membership can be
granted in different ways and can constitute different functionality. Team membership is represented in the
team's detail view, as well as the user's detail view.
• Note: Administrators do not adhere to team security and therefore can see all records.
• Explicit team membership is forged when the relationship is defined from either the team's or user's detail view.
In addition, explicit relationships are also represented with private team memberships. Explicit memberships,
other than private teams, can be removed as necessary from the team's or user's detail view. Explicit
memberships will also include membership functionality for actions such as workflows or inbound email.
• Implicit team membership is used for record visibility. Implicit membership relies on the "Reports To" field in the
User Profile. When one user reports to another, the hierarchy of the "Reports To" field is kept in tact. The user
being reported to will inherit the team membership of the subordinate user and be able to see any records on
both his or her own team, and the teams of which the subordinate user is a member. The subordinate's teams
can either be explicit or implicit teams in this scenario.
• Note: Implicit relationships cannot be removed, but the cause for their relationship can be broken by changing
the reporting hierarchy.
• In the Team's detail view, the user's subpanel will showcase which relationships are explicit and which are
implicit. In the "Membership" column of the Users subpanel, the user will either be marked as a "Member",
meaning that they are an explicit member, or "Member Reports-to", meaning they are an implicit member. In
addition, the users marked with the "Member Reports-to" will not include an "Unlink" button, as they have
another user (or users) reporting to them on this team.

9. Roles
• Sugar® roles define permissions for users such as
what kinds of records they can access and what
level of access they are allowed. Roles work in
conjunction with Teams to form a robust security
model for non-admin users in Sugar. Roles control
three different layers of access for users within
Sugar: module, field, and action-level access.

10. Setting Module-Level Permissions
Column Header Description
Module (Blank) The module for which the change is being
made
Access Select whether the user should have any
access to this module. If set to disabled,
the user will not see a module tab for the
module, any subpanels, or be able to
access any records from this module
Access Type This field can grant users the ability to
supersede team settings or access some
sections of the Admin menu
Delete Restrict users from deleting or merging
records in this module. This role setting
affects merge functionality in Sugar
because "Merge" deletes existing records
that are not rolled up to the primary
record

11. Setting Module-Level Permissions
Edit Restrict users from editing or creating
records in this module. This role setting
affects the create functionality because
the process of creating a record functions
the same way as editing
Export Restrict users from exporting data from
this module to their local computers. This
role setting affects usage of the Sugar API,
which is the framework used for external
connections, such as the Outlook Plug-in.
For more information on exporting,
please review the Export documentation
Import Restrict users from importing data into
this module. This role setting affects
usage of the Sugar API, which is the
framework used for external connections,
such as the Outlook Plug-in. For more
information on importing, please review
the Import documentation

12. Setting Module-Level Permissions
List Restrict a user's ability to see records in a
list view or subpanel. A module's list view
will not be visible for users where "List" is
set to "None”
Mass Update Restrict users from using the Mass Update
functionality in this module. The Mass
Update option will not be visible on the
list view's actions menu when "Mass
Update" is set to "None".

13. Setting Module-Level Permissions
View Restrict access to the record view of
specific records. If "View" is set to
"None", the module's list view will display
record names that are not hyperlinked to
the corresponding record view. Users with
View permission will be able to click on
the record names from list view to see the
record's details.
Note: If a module's View setting is "None"
or "Owner", the access level for "Edit"
and "List" must be set to the same value.
This will ensure desired functionality for
SugarCRM Mobile and other API-based
applications.

14. The "Access" column provides the
following options:
• Enabled : The user is allowed access to this module in
Sugar.
• Not Set : The user is neither restricted nor granted access to
this module. When permission is "Not Set" the user will
default to having "Enabled" access in Sugar.
• Disabled : The user will not be able to access this module,
view any of its records, or see any trace of its existence in
Sugar.
• Note: To ensure proper functionality, a user's access to the
Revenue Line Items and Opportunities modules should be
consistently configured. The user should not have access to
one module without access to the other.

15. The "Access Type" column provides the
following options:
• Normal : The user will be able to perform standard functions in this module
barring restrictions from other roles or team settings. The user will not have
any type of access to the Admin menu for this module.
• Not Set : The user is neither restricted nor granted access to this module.
When permission is "Not Set" the user will default to having "Normal"
access in Sugar.
• Admin : The user will supersede any Teams restrictions for this module and
be able to view all records.
• Developer : The user will be given access to the module-specific sections
of Studio, Workflow Management, Dropdown Editor, and any other
necessary menus in Admin that are specific to the module. Note: For more
information on developer tools, please refer to the Developer Tools
documentation.
• Admin & Developer : The user will be given the rights defined with the
Admin and Developer role settings.

16. The function specific columns (Edit, Delete,
etc.) provide the following options:
• All : The user will be able to perform this action on any
and all records that can be accessed in Sugar.
• Owner : The user will only be able to perform this
action if he or she is the "Assigned To" user on the
record.
• Not Set : The user is neither restricted nor granted
access to this function. When permission is "Not Set"
the user will default to having "All" access in Sugar.
• None : The user is not able to perform this action while
using this module in Sugar.

17. Setting Field-Level Permissions
• Not Set : The user is neither restricted nor granted access to this field. When
permission is "Not Set" the user will default to having "Read/Write" access.
• Read/Write : The user will be able to see the value of this field in all views and be
able to make changes to it via the record view (for Sidecar modules) or edit view
(for Legacy modules) layout.
• Read/Owner Write : The user will be able to see the value of this field in all views
but only able to make changes in the record view (for Sidecar modules) or edit view
(for Legacy modules) layout if he or she is the "Assigned To" user on the record.
• Read Only : The user will be able to see this field in all views but not make any
changes to it in Sugar.
• Owner Read/Owner Write : The user will only be able to see this field in all views
and make changes in the edit view or quick edit if he or she is the "Assigned To"
user on the record.
• None : This field will appear on the layout (e.g. Record View) but will display "No
Access" for Sidecar modules (e.g. Accounts). For Legacy modules (e.g. Quotes),
the field will not appear on any layout and will display a blank space for the edit
view and detail view layouts.

18. Role-Based Record View Layouts
• Record Views can be configured to display customized layouts based on
the viewing user's role. The availability and organization of fields may be
altered to provide only the relevant fields for each user's role according to
your business practices. When editing a particular module's record view, the
Role dropdown appearing on the top right contains all existing roles in the
Sugar application. By default, none of the Sugar roles have customized
views, so changes made to the Default role-view will automatically be
copied to the other role-views upon save. This means that as long as no
role-views are customized here, all users will continue to see the record
view layout matching the Default role-view.
• Note: It is recommended to assign each user to a maximum of one role.
Users belonging to multiple roles which each have customized role-views
may experience unexpected behavior when using record views

19. Future Webinars
Topics Subject to Change
• Topics
– Adding your own REST End Point
– Using the SugarJobQueue
– LogicHooks
– Deploying Packages
– Creating your own Custom Fields