TUESDAY, FEBRUARY 07, 2012

Category: Business rules

System security is probably one of the more challenging things to implement in Service-now.com.  While an out-of-box Service-now instance comes with the core security built-in, any implementation will inevitably have customizations in this area.  At some point, I plan on writing a basic security guide to help administrators and consultants make informed decisions about how security should be implemented in their systems.

I’ve now added the security guide I promised! Check out the ‘What Everybody Should Know about ServiceNow Security‘ article for more details!

One little-known, but extremely useful access control method is to use business rules to restrict record access in your system.  You can do this by creating what I call a ‘Before Query’ business rule.  These business rules have a ‘When’ value of ‘Before’ and also have the ‘Query’ checkbox selected.  ‘Before Query’ business rules are only used when you need to restrict access to certain rows within a table for certain groups of individuals.  Because the security is controlled by a script, the restriction can be applied based on roles, group membership, company or department information from the user record, or pretty much anything else that you can derive about the user trying to access a set of records.  There are a few of these business rules out-of-box that serve as great examples of how to implement security in this way.  When I need to implement security with a ‘Before Query’ business rule, I usually start with the ‘incident query’ business rule as my template.

Learn more ...

S

ervice-now.com provides a very robust and simple way to manage your tasks and approvals (among other things) through its graphical workflow engine.  It is very common to use graphical workflow to help facilitate some change management process within your organization.  One common requirement in change management is to be able to cancel or close the change request at any time during the process.  “Simple”, you say.  “Just allow the user to change the value of the ‘State’ field to ‘Closed’.”

You would not be incorrect in saying something like that, but you would be forgetting about part of the problem with closing or canceling a change request or other task ticket.  What if the attached workflow(s) still think that the change request and its associated tasks and approvals are still in progress?  Should the attached workflow context(s) continue to run indefinitely?  If your workflow doesn’t have a way to know about the completion of the change request then it will continue to run (or more likely just sit and be forgotten).

Learn more ...

W

hen implementing the Change management process in Service-now you’ll probably encounter a scenario where your entire change workflow (including all tasks and approvals) needs to be reset.  The first option to consider (assuming you’re using the graphical workflow engine to manage the tasks and approvals) is the Rollback workflow activity.  The rollback activity works great for a lot of scenarios, but what if you don’t have a defined point in the workflow where everything should be rolled back?  What if the rollback (or reset) can happen at any point in time?  There’s not really an easy way to handle this within the workflow itself since you would need to check for a rollback condition at an infinite number of places.

Learn more ...


Latest Comments

  • Mark Stanger: This linkage all happens for you if you use the task survey plugin. You can look on the wiki for more...
  • Vineeth: I want a way in which if a survey is filled in by the user the response are stored in the survey response...
  • Mark Stanger: This functionality doesn’t connect to an FTP server. See this line in the post above…...
  • Mark Stanger: The report page is back-end XML so there’s no way to directly manipulate the behavior of that...